Is this some kind of innovative development? Which can find a key on 4 CPU cores?
|
|
|
Dear Jean Luc, please do a search --keyspace. You are a real programmer. You can do it. I ask you to. Hope to find the key with the program BitCrack lost((( Want to find the address from the puzzle... ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Doesn't this utility do that? https://bitcointalk.org/index.php?topic=5244940.0
|
|
|
Please explain what is DP?
|
|
|
1. Using it, can I parse all addresses with a positive balance from the entire blockchain to a text file? 2. Can I check the balances of a large list of addresses from a text file and write them to another text file?
|
|
|
Could you post the compiled exe?
|
|
|
Yes, I think everyone wants to try Pollard at GPU Everyone else is embarrassed to admit ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
And what will happen to bitcoin when mining becomes unprofitable?
|
|
|
Even with higher speeds, runtime may fluctuate a lot. In order to compare performances, you need several trials.
Naturally I did a few measurements. Python scripts behaved the same way. The single-core and multi-core scripts showed approximately the same search time, although the multi-core speed was much higher.
|
|
|
why are you ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) ? scaling depends on CPU, ie # of cores (typically 2,4,8 ... or 56 if you have a Intel® Xeon® Platinum 9282 Processor ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ) and # of threads per core (which is one or two) -t is generally equal to core number ... on some cpu's you might get better performance for -t equal to 2 x core number. This is Ryzen 7 2700 (8 cores 16 threads) I understand that -t is the number of threads. The question is why the speed increases, but time does not decrease, more often it even increases.
|
|
|
-t 4 -bits 55 1.0M j/s [runtime] 00:04:01 -t 16 -bits 55 3.2M j/s [runtime] 00:04:33 ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) PS D:\btc\vs-kangaroo-0.01> ./vs-kangaroo_0.01.exe -v 1 -t 4 -bits 55 [###########################################################] [# Pollard-kangaroo PrivKey Recovery Tool #] [# (based on engine of VanitySearch 1.15) #] [# bitcoin ecdsa secp256k1 #] [# ver0.01 #] [###########################################################] [DATE(utc)] 09 Oct 2019 09:20:10 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [pow2bits] 55 [rangeW] 2^54..2^55 ; W = U - L = 2^54 [DPsize] 1024 (hashtable size) [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [pubkey#55] loaded [Xcoordinate] 85A30D8413AF4F8F9E6312400F2D194FE14F02E719B24C3F83BF1FD233A8F963 [Ycoordinate] 0EB400323654CEC63999B56F4BA44E8B21AB92D9D697FABE4666DF3678585669 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [+] Sp-table of pow2 points - ready [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [+] recalc Sp-table of multiply UV [UV] U*V=1*3=3 (0x03) [optimal_mean_jumpsize] 134217728 [meanjumpsize#30] 107374182(now) <= 134217728(optimal) <= 207820998(next) [i] Sp[30]|----------------J-------------------------------------------|Sp[31] [i] this Sp set has low efficiency (over -25%) for this mean jumpsize [JmaxofSp] Sp[30]=107374182 nearer to optimal mean jumpsize of Sp set [DPmodule] 2^25 = 33554432 (0x0000000002000000) [+] 1T+3W kangaroos - ready [CPU] threads: 4 [th][tame#1] run.. [th][wild#1] run.. [th][wild#2] run.. [th][wild#3] run.. [-][ 00:04:00 ; 1.0M j/s; 249.0Mj 92.8%; dp/kgr=1.5; 00:00:18 ] [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [prvkey#55] 0x000000000000000000000000000000000000000000000000006ABE1F9B67E114 [i] 1.0M j/s; 250.0Mj of 268.0Mj 93.4%; DP 1T+3W=2+2=4; dp/kgr=2.0; [runtime] 00:04:01 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [DATE(utc)] 09 Oct 2019 09:24:12 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [x] EXIT PS D:\btc\vs-kangaroo-0.01> ./vs-kangaroo_0.01.exe -v 1 -t 16 -bits 55 [###########################################################] [# Pollard-kangaroo PrivKey Recovery Tool #] [# (based on engine of VanitySearch 1.15) #] [# bitcoin ecdsa secp256k1 #] [# ver0.01 #] [###########################################################] [DATE(utc)] 09 Oct 2019 09:36:15 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [pow2bits] 55 [rangeW] 2^54..2^55 ; W = U - L = 2^54 [DPsize] 1024 (hashtable size) [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [pubkey#55] loaded [Xcoordinate] 85A30D8413AF4F8F9E6312400F2D194FE14F02E719B24C3F83BF1FD233A8F963 [Ycoordinate] 0EB400323654CEC63999B56F4BA44E8B21AB92D9D697FABE4666DF3678585669 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [+] Sp-table of pow2 points - ready [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [+] recalc Sp-table of multiply UV [UV] U*V=7*9=63 (0x3f) [optimal_mean_jumpsize] 536870912 [meanjumpsize#28] 603979773(now) <= 536870912(optimal) <= 1166305772(next) [i] Sp[27]|----------------------------------------------J-------------|Sp[28] [i] this Sp set has low efficiency (over -25%) for this mean jumpsize [JmaxofSp] Sp[28]=313174696 nearer to optimal mean jumpsize of Sp set [DPmodule] 2^25 = 33554432 (0x0000000002000000) [+] 7T+9W kangaroos - ready [CPU] threads: 16 [th][tame#1] run.. [th][wild#1] run.. [th][tame#3] run.. [th][tame#4] run.. [th][tame#5] run.. [th][tame#6] run.. [th][tame#7] run.. [th][tame#2] run.. [th][wild#2] run.. [th][wild#3] run.. [th][wild#4] run.. [th][wild#5] run.. [th][wild#6] run.. [th][wild#7] run.. [th][wild#9] run.. [th][wild#8] run.. [|][ 00:03:57 ; 3.2M j/s; 770.0Mj 287.1%; dp/kgr=13.5; 00:00:00 ] [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [prvkey#55] 0x000000000000000000000000000000000000000000000000006ABE1F9B67E114 [i] 2.8M j/s; 776.0Mj of 268.0Mj 289.0%; DP 7T+9W=13+14=27; dp/kgr=13.5; [runtime] 00:04:33 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [DATE(utc)] 09 Oct 2019 09:40:49 [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [x] EXIT
|
|
|
PS. It looks like you took my own example from another topic and post it here ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) Yes, I did not pay attention to who is the creator of this topic ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
Does it work only under INTEL i5-2540 and higher? Will it not work under AMD?
It works for me on AMD Ryzen 7 2700
|
|
|
Privkeys: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYpCemuaUp7NigjvtJug L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6LBVeqHTSj1w9XhwfuR (outside of bitcoins curve range) Address: 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
|
|
|
It is impossible to add to the algorithm a kangaroo so that it does not search by public key, but by address? Suppose this takes longer, but you can search for keys for addresses without an outgoing transaction. Or is the kangaroo algorithm not suitable for this?
|
|
|
people still trying to bruteforce #64?
why not? 64 and 105
|
|
|
62. Wallet
Private Key : KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYpCemuaUp7NigjvtJug
Public Key : 03231a67e424caf7d01a00d5cd49b0464942255b8e48766f96602bdfa4ea14fea8
Private Key (Hex): 363D541EB611ABEE Private Key (Decimal): 3908372542507822062
Another private key to wallet #62: HEX: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BF60FB2AB8647ED2F DEC: 115792089237316195423570985008687907852837564279074904382609071514060669316399 WIF: L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6LBVeqHTSj1w9XhwfuR Share the story how did you find another key?
|
|
|
Let's! : : to be continued..
Your post is very informative, but goes down in history, maybe you should create a separate topic?
|
|
|
|