ginky
Newbie
Offline
Activity: 44
Merit: 0
|
|
October 31, 2016, 05:22:11 PM |
|
Any news?
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 01, 2016, 06:57:18 AM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 03, 2016, 01:17:30 PM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 03, 2016, 10:21:44 PM |
|
As for #47 of the puzzle transaction: ETA is anything between 0 and 269 hours.
f828005d41b0f4fed4c8dca3b06011072cfb07d4 -> 0x6cd610b53cba have a nice day. Rico
|
|
|
|
Jude Austin
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
November 03, 2016, 11:04:36 PM |
|
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?
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 04, 2016, 08:43:11 AM |
|
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
|
|
November 04, 2016, 03:39:44 PM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 04, 2016, 03:59:30 PM |
|
And practically the multiplier will be above 1.1760793641030374 !
Would you mind to work on your excessive quoting habbits? Rico
|
|
|
|
bobsmoke
|
|
November 08, 2016, 04:24:11 PM |
|
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
|
|
|
|
|
bobsmoke
|
|
November 08, 2016, 08:52:54 PM Last edit: November 08, 2016, 09:57:18 PM by bobsmoke |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 08, 2016, 10:26:26 PM |
|
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
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
November 09, 2016, 12:36:17 AM |
|
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
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 09, 2016, 06:14:05 AM |
|
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 $ 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 $ 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
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
November 10, 2016, 12:43:13 AM |
|
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 $ 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 $ 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
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 10, 2016, 06:55:34 AM |
|
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 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
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
November 10, 2016, 11:06:34 PM |
|
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 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
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 11, 2016, 09:29:21 AM |
|
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-screenRico 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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 11, 2016, 09:48:48 AM |
|
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.goactually, 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 genh160 "block-number" > file That file is 2 x 2 20 hash160s (each 20byte). "2 x" because it's for the compressed and uncompressed public keys of the respective private key. Rico
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
November 15, 2016, 12:32:12 PM |
|
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.zipThe *-0 is from the original https://github.com/ryancdotorg/brainflayer/blob/master/ripemd160_256.cthe *-latest is mine, about 20-30% faster. Evolution may be visible: -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: 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
|
|
|
|
|