Large Bitcoin Collider (Collision Finders Pool)

[ginky]

Any news?

[1715113803]

1715113803

[1715113803]

1715113803

[1715113803]

1715113803

[1715113803]

1715113803

[rico666]

Any news?

None of any significance.

GPU generator in the making, got an alternative implementation from a member here, inspecting that, maybe merging best of both worlds.

Patience. Maybe Christmas present or maybe a New Year's resolution for LBC to go GKeys/s.


Rico

[rico666]

I've built a new .blf (and patch) with todays state of the blockchain.
Please restart your clients, so they will check for updates and download.


Rico

[rico666]

As for #47 of the puzzle transaction: ETA is anything between 0 and 269 hours.

f828005d41b0f4fed4c8dca3b06011072cfb07d4 -> 0x6cd610b53cba


have a nice day.


Rico

[Jude Austin]

As for #47 of the puzzle transaction: ETA is anything between 0 and 269 hours.

f828005d41b0f4fed4c8dca3b06011072cfb07d4 -> 0x6cd610b53cba


have a nice day.


Rico

Nice, added to my spreadsheet!

Thanks Rico!

P.S. going from my records the next key will be found between 1.1 and 3.1 times the previous decimal key found.

Starting from the first address to number 47 this is the multiplier of the previous PK decimal value:

0
3
2.333333333
1.142857143
2.625
2.333333333
1.551020408
2.947368421
2.084821429
1.100642398
2.247081712
2.322943723
1.944092434
2.021472393
2.548084219
1.917221871
1.860279557
2.073291381
1.799651682
2.414636329
2.098608043
1.659986069
1.861611443
2.577100601
2.299969103
1.643454135
2.052663677
2.033358892
1.760317772
2.578335793
2.034906801
1.471408704
2.307257358
1.980132413
1.42310685
2.107494664
2.365105799
1.466027419
2.202637167
3.100321289
1.452946896
1.985510149
2.559189118
2.07896823
1.298070259
2.570888168
2.327752465

Lowest: 1.100642398
Highest: 3.100321289

Is there a reason behind this?

[rico666]

P.S. going from my records the next key will be found between 1.1 and 3.1 times the previous decimal key found.

Starting from the first address to number 47 this is the multiplier of the previous PK decimal value:

0
3
2.333333333
1.142857143
2.625
2.333333333
1.551020408
2.947368421
2.084821429
1.100642398
2.247081712
2.322943723
1.944092434
2.021472393
2.548084219
1.917221871
1.860279557
2.073291381
1.799651682
2.414636329
2.098608043
1.659986069
1.861611443
2.577100601
2.299969103
1.643454135
2.052663677
2.033358892
1.760317772
2.578335793
2.034906801
1.471408704
2.307257358
1.980132413
1.42310685
2.107494664
2.365105799
1.466027419
2.202637167
3.100321289
1.452946896
1.985510149
2.559189118
2.07896823
1.298070259
2.570888168
2.327752465

Lowest: 1.100642398
Highest: 3.100321289

Is there a reason behind this?

There is. In theory, the multiplier between two consecutive keys can be anything between "a little bit more than 1"

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111

->

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000

and "almost 4"

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000

->

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111

  hehe - count the digits.

However, these extremes could only co-exist with their extreme counterparts for the pre-previous or the after-next key respectively.

i.e. if #M is almost 4 times smaller than #N, then #O can be at most 2 times bigger than #N and then #L would be at most nearly 2 times smaller than #M

(for the L > M > N > O sequence)

This is also the reason why the sum of two consecutive numbers in your list will never be more than 6. If you send me your spreadsheet, I'll have a look and maybe do some enhanced statistical analysis on it. I need a break from the horror that is (portable) OpenCL.


Rico

[donGeilo]

And practically the multiplier will be above 1.1760793641030374 !

P.S. going from my records the next key will be found between 1.1 and 3.1 times the previous decimal key found.

Starting from the first address to number 47 this is the multiplier of the previous PK decimal value:

0
3
2.333333333
1.142857143
2.625
2.333333333
1.551020408
2.947368421
2.084821429
1.100642398
2.247081712
2.322943723
1.944092434
2.021472393
2.548084219
1.917221871
1.860279557
2.073291381
1.799651682
2.414636329
2.098608043
1.659986069
1.861611443
2.577100601
2.299969103
1.643454135
2.052663677
2.033358892
1.760317772
2.578335793
2.034906801
1.471408704
2.307257358
1.980132413
1.42310685
2.107494664
2.365105799
1.466027419
2.202637167
3.100321289
1.452946896
1.985510149
2.559189118
2.07896823
1.298070259
2.570888168
2.327752465

Lowest: 1.100642398
Highest: 3.100321289

Is there a reason behind this?

There is. In theory, the multiplier between two consecutive keys can be anything between "a little bit more than 1"

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111

->

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000

and "almost 4"

0b10000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000

->

0b11111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111

  hehe - count the digits.

However, these extremes could only co-exist with their extreme counterparts for the pre-previous or the after-next key respectively.

i.e. if #M is almost 4 times smaller than #N, then #O can be at most 2 times bigger than #N and then #L would be at most nearly 2 times smaller than #M

(for the L > M > N > O sequence)

This is also the reason why the sum of two consecutive numbers in your list will never be more than 6. If you send me your spreadsheet, I'll have a look and maybe do some enhanced statistical analysis on it. I need a break from the horror that is (portable) OpenCL.


Rico

[rico666]

And practically the multiplier will be above 1.1760793641030374 !

Would you mind to work on your excessive quoting habbits?


Rico

[bobsmoke]

Hi, this seems a very interesting project - great work rico666!
I'm still getting familiar with it but meanwhile when I try to check my rank - for sake of curiosity - I'm getting:

$ ./LBC -q

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 2
Sleeping 8.488 s...

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 1
Sleeping 15.169 s...

thanks

[rico666]

Hi, this seems a very interesting project - great work rico666!
I'm still getting familiar with it but meanwhile when I try to check my rank - for sake of curiosity - I'm getting:

$ ./LBC -q

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 2
Sleeping 8.488 s...

Problem connecting to server http://lbc.cryptoguru.org:5000//query(status: 500 Internal Server Error). Retries left: 1
Sleeping 15.169 s...

thanks

If you are from Helvetia, https://bitcointalk.org/index.php?topic=1581701.msg16815398#msg16815398
if no, same applies here and I can translate the german text.


Rico

[bobsmoke]

If you are from Helvetia, https://bitcointalk.org/index.php?topic=1581701.msg16815398#msg16815398
if no, same applies here and I can translate the german text.

Rico

I think I understood it. So, it seems that you can fetch work but then if you stop the execution of the program that work will be lost. is that it?
What will be the best way to stop LBC in a graceful manner? Or instead would be better to use  --time <duration>?
.. and if there is no way to stop it gracefully you can just stop it and then process the blocks interval you were working with --pages  <from>-<to>, right?

thanks

[rico666]

I think I understood it. So, it seems that you can fetch work but then if you stop the execution of the program that work will be lost. is that it?

Yes.

What will be the best way to stop LBC in a graceful manner?

It's somewhat hidden in the README.txt, I will put it in the User Manual on the web pages:

You press 'e', after a while the message

END requested. (Ending this loop) Waiting for children to finish...

will appear. The LBC client will not stop immediately, but finish the
blocks in the current loop. Contrary to immediate quitting, this has
the advantage that proof of your work done is submitted to the server
and your work is not "lost".

.. and if there is no way to stop it gracefully you can just stop it and then process the blocks interval you were working with --pages  <from>-<to>, right?

If you do not stop it gracefully, the blocks will be re-issued after some time. The problem here was, that you issued the query command before your client had delivered ANY block and so the client was not yet known in the clients DB. Of course under such circumstances a query caused some stir. It's fixed now.


Rico

[Jude Austin]

I think I understood it. So, it seems that you can fetch work but then if you stop the execution of the program that work will be lost. is that it?

Yes.

What will be the best way to stop LBC in a graceful manner?

It's somewhat hidden in the README.txt, I will put it in the User Manual on the web pages:

You press 'e', after a while the message

END requested. (Ending this loop) Waiting for children to finish...

will appear. The LBC client will not stop immediately, but finish the
blocks in the current loop. Contrary to immediate quitting, this has
the advantage that proof of your work done is submitted to the server
and your work is not "lost".

.. and if there is no way to stop it gracefully you can just stop it and then process the blocks interval you were working with --pages  <from>-<to>, right?

If you do not stop it gracefully, the blocks will be re-issued after some time. The problem here was, that you issued the query command before your client had delivered ANY block and so the client was not yet known in the clients DB. Of course under such circumstances a query caused some stir. It's fixed now.


Rico

Just wanted to chime in, when I press E to end gracefully it doesn't terminate after the loop.

Unless of course it has to do it for each thread, I most likely got impatient and terminated it ungracefully.

Thanks,
Jude

[rico666]

Just wanted to chime in, when I press E to end gracefully it doesn't terminate after the loop.

Unless of course it has to do it for each thread, I most likely got impatient and terminated it ungracefully.

'E' doesn't work, but 'e' should. It's required only once ("waiting for children..." is the message signalling that it takes care of the termination of all threads)
It really should work. Please try.

On some systems I observed some weird input buffer configuration i.e. buffered although I explicitly set the input buffer to unbuffered mode.
So I have the habit of pressing 'e' followed by 'Return'. As the 'Return' doesn't hurt anything with that combination I got LBC terminated gracefully on every Linux system.

I'd be very surprised if that didn't work for you so please check.


Rico

Code:

$ LBC -c 4 -p 127702249-127705448
Loop off! Work on blocks [127702249-127705448] (3355 Mkeys)
Best generator chosen: gen-hrdcore-avx2-linux64
PAGE-TO: 127705448 PAGE-FROM: 127702249
Estimated duration: 24m 1.2833s

END requested. (Ending this loop) Waiting for children to finish...

started up LBC and immediately pressed 'e' - now it will take24 minutes before the process ends. It's of course superfluous here, because the process would have ended in manual mode anyway, but it still works. As the blocks up to 128 000 000 are done, you can test this feature with no risk like this

Code:

$ LBC -c 4 -p 1000-1100
<here press 'e'>

If it works, ok, if not, try 'e' + Return. If nothing works, please report. And you can terminate it ungracefully (Ctrl+C) with no risk.

[Jude Austin]

Just wanted to chime in, when I press E to end gracefully it doesn't terminate after the loop.

Unless of course it has to do it for each thread, I most likely got impatient and terminated it ungracefully.

'E' doesn't work, but 'e' should. It's required only once ("waiting for children..." is the message signalling that it takes care of the termination of all threads)
It really should work. Please try.

On some systems I observed some weird input buffer configuration i.e. buffered although I explicitly set the input buffer to unbuffered mode.
So I have the habit of pressing 'e' followed by 'Return'. As the 'Return' doesn't hurt anything with that combination I got LBC terminated gracefully on every Linux system.

I'd be very surprised if that didn't work for you so please check.


Rico

Code:

$ LBC -c 4 -p 127702249-127705448
Loop off! Work on blocks [127702249-127705448] (3355 Mkeys)
Best generator chosen: gen-hrdcore-avx2-linux64
PAGE-TO: 127705448 PAGE-FROM: 127702249
Estimated duration: 24m 1.2833s

END requested. (Ending this loop) Waiting for children to finish...

started up LBC and immediately pressed 'e' - now it will take24 minutes before the process ends. It's of course superfluous here, because the process would have ended in manual mode anyway, but it still works. As the blocks up to 128 000 000 are done, you can test this feature with no risk like this

Code:

$ LBC -c 4 -p 1000-1100
<here press 'e'>

If it works, ok, if not, try 'e' + Return. If nothing works, please report. And you can terminate it ungracefully (Ctrl+C) with no risk.

Technicalities! I was pressing 'e' and after the chunk it was working on it downloaded a new chunk and kept going.

I will do some more thorough testing and also log it so I have proof, hehe.

I was running 8 threads and large blocks so that may be the difference, we shall see.

Thanks Rico!

Jude

[rico666]

Technicalities! I was pressing 'e' and after the chunk it was working on it downloaded a new chunk and kept going.

I know about that. You basically pressed 'e' when the current chunk was about to end (in the last loop iteration).
The the command gets interpreted at the start of the next iteration (which it ends gracefully).

On my notebook, with -c 4 -t 10 it looks like this. "c 4" means that there are 'oooo' chunks, so

Code:

Ask for work... got blocks [131193289-131194632] (1409 Mkeys)               v latest possible time to 'e' for current round, else ending at the end of next round
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooo
Ask for work... got blocks [131209977-131211320] (1409 Mkeys)

vvvvvvv if you Ctrl+C on the beginning, there will be a promised but undelivered block, but not much work lost
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
the later you press Ctrl+C after a new round has been started,                ^^^^^^
the more work (of your computer) you lose/waste.                                   |
                                                            really bad time to press Ctrl+C

Ask for work... got blocks [131226665-131228008] (1409 Mkeys)
ooooooooooooooooooooooooooooooooooooooooooe
o
END requested. (Ending this loop) Waiting for children to finish...
ooooooooooooooooooooooooooooooooooooooooo

It looks like unnecessary much science, but the upside for this is, it takes 0 (in words: zero) CPU time to process.


Rico

[Jude Austin]

Technicalities! I was pressing 'e' and after the chunk it was working on it downloaded a new chunk and kept going.

I know about that. You basically pressed 'e' when the current chunk was about to end (in the last loop iteration).
The the command gets interpreted at the start of the next iteration (which it ends gracefully).

On my notebook, with -c 4 -t 10 it looks like this. "c 4" means that there are 'oooo' chunks, so

Code:

Ask for work... got blocks [131193289-131194632] (1409 Mkeys)               v latest possible time to 'e' for current round, else ending at the end of next round
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooo
Ask for work... got blocks [131209977-131211320] (1409 Mkeys)

vvvvvvv if you Ctrl+C on the beginning, there will be a promised but undelivered block, but not much work lost
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
the later you press Ctrl+C after a new round has been started,                ^^^^^^
the more work (of your computer) you lose/waste.                                   |
                                                            really bad time to press Ctrl+C

Ask for work... got blocks [131226665-131228008] (1409 Mkeys)
ooooooooooooooooooooooooooooooooooooooooooe
o
END requested. (Ending this loop) Waiting for children to finish...
ooooooooooooooooooooooooooooooooooooooooo

It looks like unnecessary much science, but the upside for this is, it takes 0 (in words: zero) CPU time to process.


Rico

Last night I pressed 'e' and then enter and I just logged  in and the screen session was dead, so it worked.

I was probably just impatient and using a large time of work.

Thanks again!

Jude

[rico666]

Last night I pressed 'e' and then enter and I just logged  in and the screen session was dead, so it worked.

I was probably just impatient and using a large time of work.

Good to hear.  By the way, I use tmux - even when starting it up on my local notebook.
If I have to restart the complete X window system, the LBC in tmux still survives all of
that nicely. Screen probably does the job too, but it's such an old and crufty code...

http://unix.stackexchange.com/questions/549/tmux-vs-gnu-screen


Rico


On a side note, the pool just searched 47 bits of the search space and covered the equivalent of 1.1 trillion pages on directory.io
At the current pace we are checking around 265000 pages on directory.io per second.

[rico666]

I have released the source code for the old Go generator. You can download it here.

This was used by the first versions of LBC and as you can see, it's a very stripped down version of

https://github.com/saracen/directory.io/blob/master/directory.go

actually, it's a stripped down version of the "compute" function in there.

After compilation, you can run it like

Code:

genh160 "block-number"

and it will vomit about 40MB of binary stream to your screen. 

So you might want to do

Code:

genh160 "block-number" > file

That file is 2 x 2²⁰ hash160s (each 20byte). "2 x" because it's for the compressed and uncompressed public keys of the respective private key.


Rico

[rico666]

Spent 48h quality time with RIPEMD160, have fastest C implementation of bitcoin-specific (a.k.a. 32byte input) RIPEMD160 in da world! (for 64bit CPUs)
Take that brainflayer, supervanitygen and Linux kernel!

All of this is necessary to be able to understand what I'm actually doing when programming the OpenCL code.
Learned a lot about GCC and even spent half a day f*ing assembly programming. Which is fun until you see what code the C compiler generates.
I've put the generated assembler source on the FTP server:
ftp://ftp.cryptoguru.org/LBC/source/ripemd160_256.zip

The *-0 is from the original https://github.com/ryancdotorg/brainflayer/blob/master/ripemd160_256.c
the *-latest is mine, about 20-30% faster.
Evolution may be visible:

Code:

-rw-r--r--  1 root root   34149 Nov 15 09:22 ripemd160_256-0.s
-rw-r--r--  1 root root   32182 Nov 14 11:21 ripemd160_256-1.s
-rw-r--r--  1 root root   33774 Nov 14 11:52 ripemd160_256-2.s
-rw-r--r--  1 root root   32899 Nov 14 13:08 ripemd160_256-3.s
-rw-r--r--  1 root root   32899 Nov 14 13:23 ripemd160_256-4.s
-rw-r--r--  1 root root   32724 Nov 14 14:29 ripemd160_256-5.s
-rw-r--r--  1 root root   32856 Nov 14 14:41 ripemd160_256-6.s
-rw-r--r--  1 root root   32236 Nov 14 15:02 ripemd160_256-7.s
-rw-r--r--  1 root root   29246 Nov 14 16:31 ripemd160_256-8.s
-rw-r--r--  1 root root   28825 Nov 15 10:01 ripemd160_256-9.s
-rw-r--r--  1 root root   28253 Nov 15 13:12 ripemd160_256-latest.s

I still can't believe, that the C compiler generates better assembly code than me, but then again I learned assembler on small MCUs and have not much experience on modern x86_64 architectures. If anyone believes he can manually improve the assembly in ripemd160_256-latest.s - feel free.
I also can't believe the compiler doesn't generate any AVX(2) code, so if you see optimization potential there, feel free also.

Why did I look at RIPEMD160? I benchmarked the various components in HRD-core and the result was:

Code:

29.20s     total runtime
19.82s     - 2 x RIPEMD160
13.67s     - 2 x SHA256_Update
13.60s     - 2 x bloom check
 7.98s     - 2 x SHA_Final
 0.10s     - sec256K1_ec_pubkey_batch

(results for the original code). RIPEMD160 now takes about 2 seconds less.
I'll push a new HRD-core generator to the FTP soon. No need to do anything, LBC will auto-update on startup.

Rico