Bitcoin Forum
February 21, 2019, 11:35:25 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
Author Topic: Large Bitcoin Collider (Collision Finders Pool)  (Read 167585 times)
ginky
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile WWW
October 31, 2016, 05:22:11 PM
 #261

Any news?
1550792125
Hero Member
*
Offline Offline

Posts: 1550792125

View Profile Personal Message (Offline)

Ignore
1550792125
Reply with quote  #2

1550792125
Report to moderator
1550792125
Hero Member
*
Offline Offline

Posts: 1550792125

View Profile Personal Message (Offline)

Ignore
1550792125
Reply with quote  #2

1550792125
Report to moderator
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550792125
Hero Member
*
Offline Offline

Posts: 1550792125

View Profile Personal Message (Offline)

Ignore
1550792125
Reply with quote  #2

1550792125
Report to moderator
1550792125
Hero Member
*
Offline Offline

Posts: 1550792125

View Profile Personal Message (Offline)

Ignore
1550792125
Reply with quote  #2

1550792125
Report to moderator
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 01, 2016, 06:57:18 AM
 #262

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 03, 2016, 01:17:30 PM
 #263

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 03, 2016, 10:21:44 PM
 #264

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

f828005d41b0f4fed4c8dca3b06011072cfb07d4 -> 0x6cd610b53cba


have a nice day.


Rico


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
November 03, 2016, 11:04:36 PM
 #265

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?


Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 04, 2016, 08:43:11 AM
 #266


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

 Wink 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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
donGeilo
Full Member
***
Offline Offline

Activity: 169
Merit: 100



View Profile
November 04, 2016, 03:39:44 PM
 #267

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

 Wink 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
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 04, 2016, 03:59:30 PM
 #268

And practically the multiplier will be above 1.1760793641030374 !

Would you mind to work on your excessive quoting habbits?


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
bobsmoke
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250



View Profile
November 08, 2016, 04:24:11 PM
 #269

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
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 08, 2016, 06:57:34 PM
 #270

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
bobsmoke
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250



View Profile
November 08, 2016, 08:52:54 PM
Last edit: November 08, 2016, 09:57:18 PM by bobsmoke
 #271


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
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 08, 2016, 10:26:26 PM
 #272

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



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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
November 09, 2016, 12:36:17 AM
 #273

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



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

Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 09, 2016, 06:14:05 AM
 #274

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.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
November 10, 2016, 12:43:13 AM
 #275

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

Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 10, 2016, 06:55:34 AM
 #276

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
November 10, 2016, 11:06:34 PM
 #277

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

Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 11, 2016, 09:29:21 AM
 #278

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 11, 2016, 09:48:48 AM
 #279

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

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
November 15, 2016, 12:32:12 PM
 #280

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!