Large Bitcoin Collider (Collision Finders Pool)

[rico666]

EDIT: Any difference between Intel and AMD CPUs?

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.

What specs would be the most ideal?

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

[1714825660]

1714825660

[1714825660]

1714825660

[1714825660]

1714825660

[1714825660]

1714825660

[yo-blin]

Holy Shizz...

A CPU with 20 cores xD

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

[Hamukione]

Holy Shizz...

A CPU with 20 cores xD

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

Daaaaamn...

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

[starsoccer9]

...does the server check for a response of some sort to confirm that a block was completely searched?

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

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?

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 <from>-<to> 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.

Code:

...
1475124925   127.0.0.1 [11673395, 11674010] <<< 60b725f10c9c85c70d97880dfe8191b3 (A)
1475124926   127.0.0.1 [11692283, 11692898] >>> 60b725f10c9c85c70d97880dfe8191b3 (A)
1475125025   127.0.0.2 [11668291, 11671482] <<< 3b5d5c3712955042212316173ccf37be (B)
1475125025   127.0.0.2 [11692899, 11696090] >>> 3b5d5c3712955042212316173ccf37be (B)
1475125073   127.0.0.3 [11662369, 11663844] <<< 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125073   127.0.0.3 [11696091, 11697566] >>> 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125088   127.0.0.4 [11674011, 11674036] <<< e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125089   127.0.0.4 [11697567, 11697592] >>> e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125118   127.0.0.5 [11697593, 11698960] >>> 1ff65d1e0f08af7529e9c9f0a591f263 (rico)
...

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:

Code:

[["0",10255010],[10255652,10292471],[10292937,10639099],[10639113,10928680],[10929361,10934248],[10934857,10964934],[10965579,10990212],[10990841,11036530],[11037955,11040222],[11040863,11086284],[11087069,11105776],[11106417,11133744],[11133759,11274716],[11274731,11392940],[11394309,11413182],[11413803,11437418],[11437471,11583428],[11583443,11718436],[11730757,11745286],[11751343,11754328],[3515625000000,3515625030841],...

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

Thanks, I appreciate you taking the to explain all of that, 1 small suggestion would be to have a live stream of work being done/completed, that would be quite cool. Hopefully I will get an address soon.

2 more small questions,

1. How long does the server allocate to a client to find a block before reissuing?

2. When was the balances data created?

[rico666]

1. How long does the server allocate to a client to find a block before reissuing?

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).

2. When was the balances data created?

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


Rico

[rico666]

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.

New LBC client will have slightly different time semantics.

Code:

    --time <duration>
      Time constraint in case client is in pages 'auto' mode. This
      puts an upper limit on the client runtime. Format is h:m You are
      free to enter '60' for an hour instead of '1:0' If you specify a
      pages interval, this option has no effect.

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:

Code:

# LBC -c 4 -t 1800
Limiting work to 1 day.
Fetching adequate work... got block interval [13045018-13241689] (206225 Mkeys)
-> dammit Ctrl+C

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

[rico666]

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

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

within 24-48 hours. Any bets?

Tadaa.

Code:

Fetching adequate work... got block interval [14679478-14691797]
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo80df54e1f6
12f2fc5bdc05c9d21a83aa8d20791e:c:(hex)priv:00000000000000000000000000000000000000000000000000000e02b35a358f

Rico

[Hamukione]

Eyyyyy!!! xD

Congratz xD

[johan11]

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

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

within 24-48 hours. Any bets?

Tadaa.

Code:

Fetching adequate work... got block interval [14679478-14691797]
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo80df54e1f6
12f2fc5bdc05c9d21a83aa8d20791e:c:(hex)priv:00000000000000000000000000000000000000000000000000000e02b35a358f

Rico

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

[donGeilo]

Work of a whole day gone


500 Can't connect to 62.146.128.45:5000

[Jude Austin]

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.

[starsoccer9]

Work of a whole day gone


500 Can't connect to 62.146.128.45:5000

+1 that has happened to me multiple times.

[Jude Austin]

Work of a whole day gone


500 Can't connect to 62.146.128.45:5000

+1 that has happened to me multiple times.

I noticed that will happen if you are on the website at the same time the client tries to get new work.

It almost seems like he is only allowing 1 connection per host.

[rico666]

It almost seems like he is only allowing 1 connection per host.

Unfortunately, the current client is very brittle handling timeouts. If the server doesn't answer within a few seconds you get this 500.
Currently new code is already in place that handles this gracefully and does 3 retries within 90 seconds.

Maybe I'll make that even configurable.

edit:

Done. (configurable)
And the sleeping is done like Ethernet anti-collision strategies: Progressive random waits.

Code:

# LBC -c 1 -t 1

Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 2
Sleeping 6.965 s...

Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 1
Sleeping 19.968 s...

Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 0
500 Can't connect to 128.0.0.1:5000

I believe with this the "500" should be a thing of the past.

Rico

[rico666]

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.

This would be tremendous to have. And very much needed:



(screenshot courtesy of my development server) 

Let me spell it out for you: https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS


Rico

[Jude Austin]

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.

This would be tremendous to have. And very much needed:



(screenshot courtesy of my development server) 

Let me spell it out for you: https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS


Rico

Working on it, documentation sucks ass for go-opencl.

Might use PyOpenCL. Very documentation, much information: https://documen.tician.de/pyopencl/

All I need to do is output the private key in bytes for compressed and uncompressed, correct? And in order...which is simple.

Thanks,
Jude

[rico666]

Working on it, documentation sucks ass for go-opencl.

Might use PyOpenCL. Very documentation, much information: https://documen.tician.de/pyopencl/

All I need to do is output the private key in bytes for compressed and uncompressed, correct? And in order...which is simple.

You need to output the two hash160es in bytes for compressed and uncompressed public keys (of a private key which gets incremented).

Well - it'd be a start, I could probably continue from there. We still would need the checking against either a bloom filter or a normal associative array of the funds be done on GPU also as the CPU couldn't keep up.

Every effort counts - same as relay race.

Rico

[rico666]

Work of a whole day gone

500 Can't connect to 62.146.128.45:5000

The work is not entirely gone (for you), as your client checked the (manually given) range, so you know the result of something being in there or not.
It's just that on communication with the server, the server recognized the id of your client being blacklisted (there was a history) and refused connection. So in that case, the 500 was to be expected.

If anything, the work is lost for the pool, but as is, it takes only PoWs of clients it trusts...

Rico

[rico666]

#45

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

Code:

Fetching adequate work... got block interval [19063782-19076773]
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooof0225bfc68a6e17e87cd8b5e60ae3be18f120753:c:
(hex)priv:0000000000000000000000000000000000000000000000000000122fca143c05
oooooooooooooooooooooooooooooooooooo
...

Rico

[Hamukione]

eyyy, I am nr 7 on the stats page