Topic: BSGS solver for cuda - page 6. (Read 3827 times)
I'm testing with the divisor keys on a smaller range, but its not solving the key with keyhunt. does it work the same with xpoint mode?
What's the link to the divisor script?
and how many keys can I generate with the divisor?
and how many keys can I generate with the divisor?
If you mean the one I made, it's in the Kangaroo thread, anywhere from pages 90 to 100 I think.
I think we can cut the number of baby steps made if we take into account that the correct baby step amount is going to be random-looking (in other words, no long 0 or 1 sequences).
Or at least make the baby steps take a higher bit count, decreasing the number of giant steps.
I'm thinking that we can find the numbers represented by these random bits and then calculate their multiples to use as an incrementor... not perfect but it does the trick I guess.
E.g.
5 is 101, 10 is 1010, 15 is 1111, 20 is 10100, 25 is 11001, 30 11110, ..... etc.
Special care would need to be taken to choose a number whose multiples don't make long sequences of bits, like 15: 3*5
I don't think that this randomness has any correlation to primality of numbers (or inverse correlation to it).
What's the link to the divisor script?
and how many keys can I generate with the divisor?
and how many keys can I generate with the divisor?
@Etar 
i seriously believing that there will some way to use power of GPU cores and process all BSGS inside computer memory perhaps this will give some crazy power which never been discovered or there will be bottle neck but you can confirm it when you will build such program.
assume if you have power of keyhunt and than you will make bloom in SSD [7000+ read write speed gen4]
RAM bpfile elements bpfile size bloom size
8 GB 1000000000 32 GB 5.02 GB
32 GB 5000000000 160 GB 25.11 GB
128 GB 22000000000 704 GB 110.47 GB
500 GB 90000000000 2.9 TB 451.92 GB
based on above table you can increase speed if you will utilize both bloom+bp https://github.com/iceland2k14/bsgs
so CPU cores are less powerful than cuda and i was thinking [not sure possible or not] if we load all bp in RAM and use some bloom in GPU memory perhaps their will be some dramatic speed boost
i seriously believing that there will some way to use power of GPU cores and process all BSGS inside computer memory perhaps this will give some crazy power which never been discovered or there will be bottle neck but you can confirm it when you will build such program.
assume if you have power of keyhunt and than you will make bloom in SSD [7000+ read write speed gen4]
RAM bpfile elements bpfile size bloom size
8 GB 1000000000 32 GB 5.02 GB
32 GB 5000000000 160 GB 25.11 GB
128 GB 22000000000 704 GB 110.47 GB
500 GB 90000000000 2.9 TB 451.92 GB
based on above table you can increase speed if you will utilize both bloom+bp https://github.com/iceland2k14/bsgs
so CPU cores are less powerful than cuda and i was thinking [not sure possible or not] if we load all bp in RAM and use some bloom in GPU memory perhaps their will be some dramatic speed boost
Quote
you got big mouth but less sense and knowledge Grin
i hate to tell you that grow up your knowledge & perhaps things will get more clear.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this Grin.
2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
Your English reading or comprehension is less sense and knowledge.i hate to tell you that grow up your knowledge & perhaps things will get more clear.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this Grin.
2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
I never said anything about 80 keys...you are saying you found 80 key, I took that as a single key in an 80 bit range, not 80 keys because you did not pluralize the word key. So with that, I merely said instead of trying to get someone to reprogram BSGS Cuda for multi key, run keyhunt, since it already supports multi key and if you think it is faster, then break up 120 key into however many keys you want to, 2^5, 2^20, 2^40, or however many you want to and let that program eat. I said 2^40 specifically because you said an 80 key in a blink of an eye; so 2^120/2^40 = 2^80; if you found one 80 key in a blink of an eye, maybe you find the 120 key in 80 bit range in 2 blinks of an eye.
BSGS Cuda, can find 65 bit key in less than a second, it all depends on your hardware.
you say
Quote
if you will load 2 keys, you will make keyhunt speed half
the same will happen to BSGS Cuda; so I am not sure what your point is really. maybe you find the 120 key in 80 bit range in 2 blinks of an eye.
ok learn basic knowledge of divisor bro , if you will do 32 times, only one key will be from 5 bit down range on unknown position other all will from uper bit ranges on exact same distance from their references values.
now if you will do 2^40, you will have 1208925819614629174706176 reference values in 256 bit range and only one of key will be in 40bit range other all keys will from uper bits on exact distance from their respectively reference values.
now how the hell you can work with such large number of keys and the line you said that get the 2^40 is aggressive comment without knowing my intention.
my intention is that i already did divisor of 32 and loaded keys in Keyhunt and running it right now and i know how much speed and power i am getting from that , but i just dont know power of BSGScuda if i will load 32 keys parallel in that. so i asked Etar that if he can make such possibility who knows BSGS will out performed keyhunt.
now come to the point in above post Etar said that my program is good until 80 bit and above that use JL kangaroo so i was comparing it with BSGS of alberto but i found that CPU based BSGS is more powerful than 3080 if you have good specification hardware but same time BSGScuda is better than keyhunt[CPU] if you dont have enough power of CPU and memory.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this
.2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
I don`t have 3080 card but i think speed will be around 1400Mkeys x BabyArraySize
windows10 eat 20% of GPU memory so 3080 should have 8192 free memory, so we can use -w 30
Totaly 1400mkeys = 2^30.38 and baby array x2 = 2^31 and full perfomance = 2^61.38 and to check full 2^64 need 6.14s
Only Kangaroo can solve keys faster then bsgs or keyhunt or whatever.
Bsgs cuda created only because i didn`t find bsgs for gpu (maybe it useless app i don`t know)
i am not arguing on your math but if you have time and hardware please just try to do research on keyhunt [CPU+memory ] and by the way i appreciate your programing skills toward cuda its really impressive and wish some day you will enhanced it more to overcome 120 and by the way i know one guy who is running it with 9+Ekeys/sec [yoyodapro].
but with divisor you can get only get 1 key out of 1073741824 if you want to reach 90bit.
i loaded all keys in keyhunt and i am trying my luck but on other side i was hoping if we can figure it out how to load multi keys with cudabsgs . so i will keep busy my 3080 for that as that one is just sitting idle now.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this
.2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
I don`t have 3080 card but i think speed will be around 1400Mkeys x BabyArraySize
windows10 eat 20% of GPU memory so 3080 should have 8192 free memory, so we can use -w 30
Totaly 1400mkeys = 2^30.38 and baby array x2 = 2^31 and full perfomance = 2^61.38 and to check full 2^64 need 6.14s
Only Kangaroo can solve keys faster then bsgs or keyhunt or whatever.
Bsgs cuda created only because i didn`t find bsgs for gpu (maybe it useless app i don`t know)
Quote
you got big mouth but less sense and knowledge Grin
i hate to tell you that grow up your knowledge & perhaps things will get more clear.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this Grin.
2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
Your English reading or comprehension is less sense and knowledge.i hate to tell you that grow up your knowledge & perhaps things will get more clear.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this Grin.
2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
I never said anything about 80 keys...you are saying you found 80 key, I took that as a single key in an 80 bit range, not 80 keys because you did not pluralize the word key. So with that, I merely said instead of trying to get someone to reprogram BSGS Cuda for multi key, run keyhunt, since it already supports multi key and if you think it is faster, then break up 120 key into however many keys you want to, 2^5, 2^20, 2^40, or however many you want to and let that program eat. I said 2^40 specifically because you said an 80 key in a blink of an eye; so 2^120/2^40 = 2^80; if you found one 80 key in a blink of an eye, maybe you find the 120 key in 80 bit range in 2 blinks of an eye.
BSGS Cuda, can find 65 bit key in less than a second, it all depends on your hardware.
you say
Quote
if you will load 2 keys, you will make keyhunt speed half
the same will happen to BSGS Cuda; so I am not sure what your point is really. well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
Possible to make pseudo-parallelism (this means finding the keys sequentially at each giant step). But the speed will drop in multiples of the number of search keys.
For ex. with search 1 public key your speed is 1000mkeys/s. if you setup 10 keys the speed will drop to 100mkey/s, with 1000keys speed drop to 1mkeys/s
By the way the search time for 16 keys will be exactly the same, either in a sequential search or in a pseudo-parallel.
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you. but if the key is on position 30 program will hang with full range scan for key 1 and than will be back to second (my guess ~ didn't test your program) one perhaps after this century
but one thing that i noticed Alberto keyhunt [updated recently] is way too faster than BSGScuda [although both have different way]. i solved 80 key with blink of eye but that one need serious K and N optimization ~ do the wrong K and N you will never reach the goal. i am not sure if you guys have a chance to test that one Alberto KEYHUNT you will find it interesting.
but dark fact is keyhunt is ram eating bug
so if have less ram (minimum 128gb) no point to compare it with BSGScuda perhaps in that case BSGScuda will do way better than Keyhunt. and if you are going for this:
Quote
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you
then just do your 32 divisor and let it search each pubkey for 1 minute; maybe lucky you.you got big mouth but less sense and knowledge
i hate to tell you that grow up your knowledge & perhaps things will get more clear.
1 > 80 key not 80 keys [single key] [random mode with 4.7 Ekeys/sec] [4300000000000000000 keys/sec] [3BACAB37B62E0000 keys/sec][ whole 65 range in 1 sec]. now compare with bsgscuda
with reference key in range 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff. let me guess 3080 took with full
optimization around 17 second but keyhunt took just 1 second. even i have to reduce k and n value to reduce speed for this
.2 > do your research and than find how many keys you will get while doing 120 to 2^40 divisor [lol]. if you will load 2 keys, you will make keyhunt speed half and what about billion keys . speed will be just like your mind
processing to understand my answer.
Hi Etar what settings have you used to get that, and could you recommend what to use for a 3080?
Thanks Relic
It is unpublished version yet(i will publish it today)Thanks Relic
it is my settings for 2080ti
-t 512 -b 136 -p 480 -w 30 -htsz 28
Utilized around 9200mb of GPU memory(totaly 2080ti in windows10 have only 9240 free memory)
P.s.Already released v1.6.0
well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
Possible to make pseudo-parallelism (this means finding the keys sequentially at each giant step). But the speed will drop in multiples of the number of search keys.
For ex. with search 1 public key your speed is 1000mkeys/s. if you setup 10 keys the speed will drop to 100mkey/s, with 1000keys speed drop to 1mkeys/s
By the way the search time for 16 keys will be exactly the same, either in a sequential search or in a pseudo-parallel.
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you. but if the key is on position 30 program will hang with full range scan for key 1 and than will be back to second (my guess ~ didn't test your program) one perhaps after this century
but one thing that i noticed Alberto keyhunt [updated recently] is way too faster than BSGScuda [although both have different way]. i solved 80 key with blink of eye but that one need serious K and N optimization ~ do the wrong K and N you will never reach the goal. i am not sure if you guys have a chance to test that one Alberto KEYHUNT you will find it interesting.
but dark fact is keyhunt is ram eating bug
so if have less ram (minimum 128gb) no point to compare it with BSGScuda perhaps in that case BSGScuda will do way better than Keyhunt. and if you are going for this:
Quote
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you
then just do your 32 divisor and let it search each pubkey for 1 minute; maybe lucky you.well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
Possible to make pseudo-parallelism (this means finding the keys sequentially at each giant step). But the speed will drop in multiples of the number of search keys.
For ex. with search 1 public key your speed is 1000mkeys/s. if you setup 10 keys the speed will drop to 100mkey/s, with 1000keys speed drop to 1mkeys/s
By the way the search time for 16 keys will be exactly the same, either in a sequential search or in a pseudo-parallel.
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you. but if the key is on position 30 program will hang with full range scan for key 1 and than will be back to second (my guess ~ didn't test your program) one perhaps after this century
but one thing that i noticed Alberto keyhunt [updated recently] is way too faster than BSGScuda [although both have different way]. i solved 80 key with blink of eye but that one need serious K and N optimization ~ do the wrong K and N you will never reach the goal. i am not sure if you guys have a chance to test that one Alberto KEYHUNT you will find it interesting.
but dark fact is keyhunt is ram eating bug
so if have less ram (minimum 128gb) no point to compare it with BSGScuda perhaps in that case BSGScuda will do way better than Keyhunt. This is the maximum that I can squeeze out of my 2080ti card:
16 pubkeys from JLP example solved in 1m 23s
Used two hashtables:
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
Hi Etar what settings have you used to get that, and could you recommend what to use for a 3080?16 pubkeys from JLP example solved in 1m 23s
Code:
NewFINDpubkey= (2375c86aa2a807fd50e4b1a2a65820244e704b8eabc8eb4dc0517393aff0c647, fad56264ae29d620205a68792091b64ae262bba359f8d013ce904d595e790ccf)
***************************
GPU#0 Cnt:0000000000000000000000000000000000000000000000000000000000000001
GPU#0 Cnt:0000000000000000000000000000000000000000000000003388000000000001 823MKey/s x1073741824 2^29.69 x2^31=2^60.69
GPU#0 Cnt:0000000000000000000000000000000000000000000000006754000000000001 826MKey/s x1073741824 2^29.69 x2^31=2^60.69
***********GPU#0************
KEY!!>49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e7ad38337c7f173c7
Pub: 55b95bef84a6045a505d015ef15e136e0a31cc2aa00fa4bca62e5df215ee981b3b4d6bce33718dc6cf59f28b550648d7e8b2796ac36f25ff0c01f8bc42a16fd9
****************************
Found in 5 seconds
GPU#0 job finished
Working time 00:01:23s
Total time 00:06:00s
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
Thanks Relic
well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
Possible to make pseudo-parallelism (this means finding the keys sequentially at each giant step). But the speed will drop in multiples of the number of search keys.
For ex. with search 1 public key your speed is 1000mkeys/s. if you setup 10 keys the speed will drop to 100mkey/s, with 1000keys speed drop to 1mkeys/s
By the way the search time for 16 keys will be exactly the same, either in a sequential search or in a pseudo-parallel.
This is the maximum that I can squeeze out of my 2080ti card:
16 pubkeys from JLP example solved in 1m 23s
Used two hashtables:
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
16 pubkeys from JLP example solved in 1m 23s
Code:
NewFINDpubkey= (2375c86aa2a807fd50e4b1a2a65820244e704b8eabc8eb4dc0517393aff0c647, fad56264ae29d620205a68792091b64ae262bba359f8d013ce904d595e790ccf)
***************************
GPU#0 Cnt:0000000000000000000000000000000000000000000000000000000000000001
GPU#0 Cnt:0000000000000000000000000000000000000000000000003388000000000001 823MKey/s x1073741824 2^29.69 x2^31=2^60.69
GPU#0 Cnt:0000000000000000000000000000000000000000000000006754000000000001 826MKey/s x1073741824 2^29.69 x2^31=2^60.69
***********GPU#0************
KEY!!>49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e7ad38337c7f173c7
Pub: 55b95bef84a6045a505d015ef15e136e0a31cc2aa00fa4bca62e5df215ee981b3b4d6bce33718dc6cf59f28b550648d7e8b2796ac36f25ff0c01f8bc42a16fd9
****************************
Found in 5 seconds
GPU#0 job finished
Working time 00:01:23s
Total time 00:06:00s
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
i optimized parameters and the key
"59A3BFDAD718C9D3FAC7C187F1139F0815AC5D923910D516E186AFDA28B221DC994327554CED887 AAE5D211A2407CDD025CFC3779ECB9C9D7F2F1A1DDF3E9FF8"
i solved in 17 seconds
well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
This is the maximum that I can squeeze out of my 2080ti card:
16 pubkeys from JLP example solved in 1m 23s
Used two hashtables:
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
16 pubkeys from JLP example solved in 1m 23s
Code:
NewFINDpubkey= (2375c86aa2a807fd50e4b1a2a65820244e704b8eabc8eb4dc0517393aff0c647, fad56264ae29d620205a68792091b64ae262bba359f8d013ce904d595e790ccf)
***************************
GPU#0 Cnt:0000000000000000000000000000000000000000000000000000000000000001
GPU#0 Cnt:0000000000000000000000000000000000000000000000003388000000000001 823MKey/s x1073741824 2^29.69 x2^31=2^60.69
GPU#0 Cnt:0000000000000000000000000000000000000000000000006754000000000001 826MKey/s x1073741824 2^29.69 x2^31=2^60.69
***********GPU#0************
KEY!!>49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e7ad38337c7f173c7
Pub: 55b95bef84a6045a505d015ef15e136e0a31cc2aa00fa4bca62e5df215ee981b3b4d6bce33718dc6cf59f28b550648d7e8b2796ac36f25ff0c01f8bc42a16fd9
****************************
Found in 5 seconds
GPU#0 job finished
Working time 00:01:23s
Total time 00:06:00s
first for GPU without xpoint position, only xpoint 32bit + size htsz, totaly 32+29 = 61bit per xpoint
Second for host usage with xpoint position
Utilized 9008Mb of GPU memory.
Agreed...really, can it be bumped up to a 160-bit store plus the 2 flag bits, easier than the 254-bit store? Then the program could at least cover up to the last 160 bit key for the puzzle/challenge transaction.
254 bits is easier to make than 160 bits because I can just update the structures from
int128_t
to int256_t
in all occurrences without having to make any other changes.
Yep he was referring to mine.
You should not try to update it to 256-bit store - it's too complicated since you'll have to find a new home for the two flag bits at the end of each store (the ones which limit to the actual search range to 126 bits). This is how the hashtable got screwed.
It is more logical to update it to a 254-bit store instead so you don't have to move the flag bits anywhere.
You should not try to update it to 256-bit store - it's too complicated since you'll have to find a new home for the two flag bits at the end of each store (the ones which limit to the actual search range to 126 bits). This is how the hashtable got screwed.
It is more logical to update it to a 254-bit store instead so you don't have to move the flag bits anywhere.
In a meantime I found that your updated Div() is faulty, why not to keep original functions? And it seems more functions are faulty that are tested in Check()
you can try this: (gives wrong results)
I would be probably the happiest man in universe if with all your knowledge and experience just updated 125bit version to 254bit version, just absolutely unnecessary staff without any improvements
then I see your great success!!// Div -------------------------------------------------------------------------------------------
tTotal = 0.0;
ok = true;
for (int i = 0; i < 2 && ok; i++) {
a.SetBase16("D51263D15FC81DE32C5CB69070ABDF3D58A2028184E15F3A6C56EB8A787C81DB");
b.SetBase16("2AED15B34BE1B98EE4246FB3F447059A");
// a.Rand(BISIZE);
//b.Rand(BISIZE/2);
d.Set(&a);
e.Set(&b);
printf("a= %s\n", a.GetBase16().c_str());
printf("b= %s\n", b.GetBase16().c_str());
printf("d= %s\n", d.GetBase16().c_str());
printf("e= %s\n", e.GetBase16().c_str());
t0 = Timer::get_tick();
a.Div(&b, &c);
printf("a/b= %s\n", a.GetBase16().c_str());
printf("rem= %s\n", c.GetBase16().c_str());
t1 = Timer::get_tick();
tTotal += (t1 - t0);
a.Mult(&e);
a.Add(&c);
if (!a.IsEqual(&d)) {
ok = false;
printf("Div() Results Wrong \nN: %s\nD: %s\nQ: %s\nR: %s\n",
d.GetBase16().c_str(),
b.GetBase16().c_str(),
a.GetBase16().c_str(),
c.GetBase16().c_str()
);
return;
}
Quote
I continue to work to migrate also Kangaroo256 to r1 curve but I was told by the author to wait a bit until he updates hastables (?)
Not sure which author you are referring to, but if this is NotATether's version, I would not use it. Very buggy and last known speed is compromised and the program does not find keys.
The only thing needed, IMO, to upgrade JLPs original Kangaroo to be able to search a 256 bit range, was to update the limited 128 bit store function to a 256 bit store function (plus the + - and type bits) so the program could solve key. I have not looked at the code of the new 256bit version, but it seems it does not find keys.
Original JLP Kangaroo, you can search a 256 bit range for a key but since it only stores 128 bits for the distances, you will not solve key properly because it is missing 128 bits of the distance (private key), which is needed to reconstruct the private key of the pub key you are searching for.
Yep he was referring to mine.
You should not try to update it to 256-bit store - it's too complicated since you'll have to find a new home for the two flag bits at the end of each store (the ones which limit to the actual search range to 126 bits). This is how the hashtable got screwed.
It is more logical to update it to a 254-bit store instead so you don't have to move the flag bits anywhere.
Quote
I continue to work to migrate also Kangaroo256 to r1 curve but I was told by the author to wait a bit until he updates hastables (?)
Not sure which author you are referring to, but if this is NotATether's version, I would not use it. Very buggy and last known speed is compromised and the program does not find keys.
The only thing needed, IMO, to upgrade JLPs original Kangaroo to be able to search a 256 bit range, was to update the limited 128 bit store function to a 256 bit store function (plus the + - and type bits) so the program could solve key. I have not looked at the code of the new 256bit version, but it seems it does not find keys.
Original JLP Kangaroo, you can search a 256 bit range for a key but since it only stores 128 bits for the distances, you will not solve key properly because it is missing 128 bits of the distance (private key), which is needed to reconstruct the private key of the pub key you are searching for.
Yep he was referring to mine.
You should not try to update it to 256-bit store - it's too complicated since you'll have to find a new home for the two flag bits at the end of each store (the ones which limit to the actual search range to 126 bits). This is how the hashtable got screwed.
It is more logical to update it to a 254-bit store instead so you don't have to move the flag bits anywhere.
Jump to: