Is this project losing steam?
Yes, every project based on free electricity is nonsense.
I hate to see so much talent wasted on nonsensical projects.
Topic: Large Bitcoin Collider (Collision Finders Pool) - page 46. (Read 193484 times)
Yes, every project based on free electricity is nonsense.
I hate to see so much talent wasted on nonsensical projects.
Is this project losing steam?
Come on colliders!
Come on colliders!
LBC going down around 20:00 UTC, downtime about 30 minutes. (= should be up 20:30 UTC)
New IP will be 185.157.21.48, should the DNS not catch up soon enough, you could enter that in your /etc/hosts
for lbc.cryptoguru.org
Rico
edit:
Server up since 20:40, clients pouring in again. :-) Thanks for the patience.
New IP will be 185.157.21.48, should the DNS not catch up soon enough, you could enter that in your /etc/hosts
for lbc.cryptoguru.org
Rico
edit:
Server up since 20:40, clients pouring in again. :-) Thanks for the patience.
I let it run overnight and tried running it again. This is the result.
LOL.
By typing something which belongs on the command line as input to the LBC itself, all it got was "q" which it interprets as QUIT.
Try to input the query command on the commad line. In your case like this:
Code:
[osboxes@osboxes collider]$ ./LBC -q
And you should actually see an output similar to this:
Code:
Server answer to 'query' is:
{
"lastsee" : 1479426435,
"ips" : {
"111.222.111.222" : 3104,
"192.65.33.65" : 234
},
"done" : 2817168
}
'done' means we have delivered 2954.015 valid Gkeys.
You have to distinguish between "when the program runs" (then it listens to the keys "e" - end and "q" - quit)
and "when you are on command line" (then you basically are starting LBC)
Rico
Earlier I ran ./LBC -q to see my status, and it quit. Going to have to reread the thread to work everything out.
Which happens if you query the status before having delivered a single block.
Before rereading the thread, I'd suggest the manual: http://lbc.cryptoguru.org:5000/man/user
where I try to have the distilled information from the thread.
RIco
http://imgur.com/x4kmUC7
I let it run overnight and tried running it again. This is the result.
Sunday evening (UTC) the LBC server will move to newer greener pastures and there will be a downtime of about 30 minutes.
Because this is longer than the retry-time of the clients, they need to be restarted after that.
I'd suggest to start your clients with "-t 30" so in any case there would not be much work lost.
I'll probably PING here shortly before we shutdown and move the server.
Rico
Because this is longer than the retry-time of the clients, they need to be restarted after that.
I'd suggest to start your clients with "-t 30" so in any case there would not be much work lost.
I'll probably PING here shortly before we shutdown and move the server.
Rico
cool project, good luck!!!
Earlier I ran ./LBC -q to see my status, and it quit. Going to have to reread the thread to work everything out.
Which happens if you query the status before having delivered a single block.
Before rereading the thread, I'd suggest the manual: http://lbc.cryptoguru.org:5000/man/user
where I try to have the distilled information from the thread.
RIco
I gave up and decided to just run it in a VM. Seems to be working well so far. Still trying to remember all the commands. Earlier I ran ./LBC -q to see my status, and it quit. Going to have to reread the thread to work everything out.
On another note, after installing the VM, it gave me the MD5 doesn't match error. I solved this by doing as someone else in the thread suggested and using
It took a minute to redownload the necessary files, but it worked fine after that.
On another note, after installing the VM, it gave me the MD5 doesn't match error. I solved this by doing as someone else in the thread suggested and using
Code:
rm funds*
Code:
rm 4a*
It took a minute to redownload the necessary files, but it worked fine after that.
I'm new to Linux, so please forgive my stupid questions. Ive installed the required programs listed in your manual, but when I try to run the script, I get the "command not found" error. I'm running it with sudo.
I also tried using "sudo perl LBC.pl -h" after searching for a while, but it returns a BIGNUM error and says that JSON isn't installed.
I installed the necessary programs and downloaded your script to my desktop. Am I missing something obvious?
I also tried using "sudo perl LBC.pl -h" after searching for a while, but it returns a BIGNUM error and says that JSON isn't installed.
I installed the necessary programs and downloaded your script to my desktop. Am I missing something obvious?
It does not need the .pl extension, but you may need to invoke it like that
Code:
sudo ./LBC -h
the ./ is necessary, because . (the current PATH) is often not in the $PATH environment variable.
The messages upon 1st invocation are plenty and may look quite disturbing.
(the program is mentioning what is not installed and will install the required modules. During that installation, it shows the output of the installation, which is terse.)
Let the program vomit and wait for a while, eventually all will settle and the help will appear.
Rico
I'm new to Linux, so please forgive my stupid questions. Ive installed the required programs listed in your manual, but when I try to run the script, I get the "command not found" error. I'm running it with sudo.
I also tried using "sudo perl LBC.pl -h" after searching for a while, but it returns a BIGNUM error and says that JSON isn't installed.
I installed the necessary programs and downloaded your script to my desktop. Am I missing something obvious?
I also tried using "sudo perl LBC.pl -h" after searching for a while, but it returns a BIGNUM error and says that JSON isn't installed.
I installed the necessary programs and downloaded your script to my desktop. Am I missing something obvious?
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:
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:
(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
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
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
and it will vomit about 40MB of binary stream to your screen.
So you might want to do
That file is 2 x 220 hash160s (each 20byte). "2 x" because it's for the compressed and uncompressed public keys of the respective private key.
Rico
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 220 hash160s (each 20byte). "2 x" because it's for the compressed and uncompressed public keys of the respective private key.
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.
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.
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
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
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.
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
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
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.
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
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.
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.
Quote
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:
Quote
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".
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".
Quote
.. 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 -, 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
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.
Quote
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:
Quote
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".
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".
Quote
.. 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 -, 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
Jump to: