batareyka
Jr. Member
Offline
Activity: 38
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2021, 05:22:22 PM |
|
Hi everybody. I read a very interesting topic. I have a question. How do you know in which exact range is this or that address?
For example, take any address
1AnQDYo81Ta4VcSbeQNWp9CwPcsZqRvPGD How to find out in what range its private key?
I apologize if the question is stupid.
|
|
|
|
GoldTiger69
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2021, 05:53:43 PM |
|
Hi everybody. I read a very interesting topic. I have a question. How do you know in which exact range is this or that address?
For example, take any address
1AnQDYo81Ta4VcSbeQNWp9CwPcsZqRvPGD How to find out in what range its private key?
I apologize if the question is stupid.
You can't, that's why Bitcoin is secure (by now).
|
|
|
|
batareyka
Jr. Member
Offline
Activity: 38
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2021, 06:09:31 PM |
|
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7168
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2021, 06:21:58 PM |
|
The private keys were deliberately generated within those ranges by the author. The ranges themselves weren't calculated. So it's like the author made #64's private key between ranges 2^64 and 2^65-1, #65 between 2^65 and 2^66-1, and so on.
|
|
|
|
batareyka
Jr. Member
Offline
Activity: 38
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2021, 06:26:20 PM |
|
I am very grateful to you for your answer. GoldTiger69 NotATether
P.S. It is a pity that this puzzle has already exhausted itself, there are literally 1-3 addresses left that can be obtained, the rest will remain unattainable.
|
|
|
|
unclevito
Jr. Member
Offline
Activity: 74
Merit: 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 03:13:28 AM |
|
The private keys were deliberately generated within those ranges by the author. The ranges themselves weren't calculated. So it's like the author made #64's private key between ranges 2^64 and 2^65-1, #65 between 2^65 and 2^66-1, and so on. why at certain times the kangaroo program start to accumulate dead kangaroos? does this give any indication as to solving the the puzzle
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 03:35:41 AM |
|
The private keys were deliberately generated within those ranges by the author. The ranges themselves weren't calculated. So it's like the author made #64's private key between ranges 2^64 and 2^65-1, #65 between 2^65 and 2^66-1, and so on. why at certain times the kangaroo program start to accumulate dead kangaroos? does this give any indication as to solving the the puzzle Not really. I don't know what range you are running but normally they start accumulating when running through a small range. There is limited space in smaller range so the kangaroos in the same herd start to trip over each other. But if you do get dead kangaroos in a larger range, no worries, the program automatically resets them to different random points.
|
|
|
|
unclevito
Jr. Member
Offline
Activity: 74
Merit: 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 03:49:09 AM |
|
The private keys were deliberately generated within those ranges by the author. The ranges themselves weren't calculated. So it's like the author made #64's private key between ranges 2^64 and 2^65-1, #65 between 2^65 and 2^66-1, and so on. why at certain times the kangaroo program start to accumulate dead kangaroos? does this give any indication as to solving the the puzzle Not really. I don't know what range you are running but normally they start accumulating when running through a small range. There is limited space in smaller range so the kangaroos in the same herd start to trip over each other. But if you do get dead kangaroos in a larger range, no worries, the program automatically resets them to different random points. Yes the full range of 120
|
|
|
|
brainless
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 318
Merit: 34
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 11:00:45 AM |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ?
|
13sXkWqtivcMtNGQpskD78iqsgVy9hcHLF
|
|
|
bigvito19
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 12:57:21 PM |
|
What to use to look at the DP's I have in the workfiles?
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 03:05:48 PM |
|
What to use to look at the DP's I have in the workfiles?
If you can compile your own version, you can add the export option that https://github.com/PatatasFritas/FriedKangaroo created. If you search for PatatasFritas in this thread, they also have a python script that will do the same; export the wild and tame files.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 04:07:41 PM |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range?
|
|
|
|
brainless
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 318
Merit: 34
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 21, 2021, 04:11:45 PM |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range
|
13sXkWqtivcMtNGQpskD78iqsgVy9hcHLF
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 12:38:58 AM Last edit: June 22, 2021, 12:51:30 AM by WanderingPhilospher |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range Did you cut it by 800000000000000000000000000000 to drop it down one range before cutting down to 110? Could mean the difference in 2^110 versus 2^109
|
|
|
|
unclevito
Jr. Member
Offline
Activity: 74
Merit: 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 03:06:15 AM |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range Did you cut it by 800000000000000000000000000000 to drop it down one range before cutting down to 110? Could mean the difference in 2^110 versus 2^109 I have heard that the key space for 120 can be compressed but how?
|
|
|
|
brainless
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 318
Merit: 34
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 05:32:27 AM |
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example 03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854 030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854 029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577 03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577 03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300 0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range Did you cut it by 800000000000000000000000000000 to drop it down one range before cutting down to 110? Could mean the difference in 2^110 versus 2^109 No cut it by 800000000000000000000000000000 exact 110 bit range 16/260 ( 2^109 to 2^110-1 )
|
13sXkWqtivcMtNGQpskD78iqsgVy9hcHLF
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 06:36:24 AM |
|
I have heard that the key space for 120 can be compressed but how? Jean Luc's program (the one this thread is about) automatically subtracts the inputted start range.
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7168
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 09:18:03 AM |
|
~
if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range Why are you searching 16 pubkeys at once in 110bit when there's only one pubkey for #110? Runtime increases linearly with respect to the number of pubkeys, and when solving 1 pubkey, the runtime is already exponentially high, so you can't really find pubkeys quicker by batching them together in the same command invocation.
|
|
|
|
Siberian047
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 01:31:54 PM |
|
Search speed will increase or not if you use: - HDD, SSD, M.2 or DDR vertual disk? -32 cores or 64 processor cores?
|
|
|
|
_Counselor
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 107
Merit: 61
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2021, 03:03:39 PM |
|
Search speed will increase or not if you use: - HDD, SSD, M.2 or DDR vertual disk? -32 cores or 64 processor cores?
HDD speed doesn't matters. If you using CPU then more cores => more threads => more speed.
|
|
|
|
|