Latest posts of: albert0bsd

Show Posts
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 »

761	Economy / Games and rounds / Re: Can someone try brute force this pu in 80 bit range ?	on: April 05, 2022, 04:41:34 PM
Quote from: COBRAS on April 05, 2022, 04:16:22 PM No Guaranty, but, if point go to negative side, I was provide range for this negative side.. 80 bit That is also NOT true, it can be in under the 2^120 Negative. Quote from: COBRAS on April 05, 2022, 04:16:22 PM we share with him some cents... Some cents??

762	Economy / Games and rounds / Re: Can someone try brute force this pu in 80 bit range ?	on: April 05, 2022, 04:15:07 PM
That subtraction DON'T guaranty that the result is under 80 bits.

763	Economy / Games and rounds / Re: Can someone try brute force this pu in 80 bit range ?	on: April 05, 2022, 04:00:27 PM
how do you can be 100% sure that the key is in the 80 bits range?

764	Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys	on: April 05, 2022, 03:52:17 PM
Quote from: COBRAS on April 05, 2022, 03:43:15 PM This is good idea I think, but real hard. It is what the BSGS algorithm internally do.

765	Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys	on: April 05, 2022, 03:36:44 PM
You only can determine if some publickey is bigger than another publickey if they are NEAR to each other. Example: Let to suppose that there are two private keys A and B and A > B If P(A) > P(B) then P(A) - P(B) = P(C) Then P(C) is a positive Value if the value of C is under some low bit range lets to say less than 2^70 (70 bits) you can determine the value of P(C) with some tool like kangaroo of BSGS easily with no effort So ONLY if the Difference P(A) - P(B) or P(B) - P(A) is under some value easy to find you can know which one of those publickeys are bigger. If the difference is bigger than 90 bits or something other high value then you CAN NOT know it. Unless you have some GPU farm to calculate those values. Example: Code: P(A) = 025004d7d9c2a3b2d675ada618d9ceda55d1f6a9fdf263e24daa8cbea586af2b2b P(B) = 02fde2347f83e21198fc48b918f5657c188ffcdd8611b39b987230addb91d05d80 Differences: P(A) - P(B) = 0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 P(B) - P(A) = 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 Solve it with keyhunt: Code: $ cat input.txt 0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 $ ./keyhunt -m bsgs -f input.txt -k 128 -t 4 -S -r 1:100000000000000 [+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD [+] K factor 128 [+] Threads : 4 [+] Mode BSGS secuential [+] Opening file input.txt [+] Added 2 points from file [+] Range [+] -- from : 0x1 [+] -- to : 0x100000000000000 [+] N = 0x100000000000 [+] Bloom filter for 536870912 elements : 1840.33 MB [+] Bloom filter for 16777216 elements : 57.51 MB [+] Bloom filter for 524288 elements : 1.80 MB [+] Allocating 8.00 MB for 524288 bP Points [+] Reading bloom filter from file keyhunt_bsgs_4_536870912.blm .... Done! [+] Reading bloom filter from file keyhunt_bsgs_6_16777216.blm .... Done! [+] Reading bP Table from file keyhunt_bsgs_2_524288.tbl .... Done! [+] Reading bloom filter from file keyhunt_bsgs_7_524288.blm .... Done! [+] Thread Key found privkey 1 [+] Publickey 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 [+] Thread 0xfff00000000001 End The value of 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 is 1 Positive then if the result of the subtraction P(B) - P(A) is positive, hence P(B) > P(A) for this example. @PawGo sorry to divert your topic, but i want to reply that question.

766	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 10, 2022, 09:15:51 PM
Yes in a perfect bsgs that is the amount: (2^120)^(1/2) = 1152921504606846976 = 2^60 But just make the calculations how many memory is necessary to store 2^60 of precalculated data using 20 bytes per item in the bloom filter and hashtable: 20971520 Terabytes of RAM And that is only the first part (Baby steps) we need to iterate over the other half 2^60 to make subtractions of the publickey with our current range (Giant step).

767	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 09, 2022, 04:37:57 PM
Quote from: PrivatePerson on March 09, 2022, 07:49:11 AM 1. How to split the private key into parts and brute through it in parts? I will explain this one using only privatekeys. But remember that those calculations depend only if you already have the TARGET PUBLICKEY. if you don't have the publickey this example doesn't apply. Lets to asume that we have the key like you example: Code: e3b0c44**c1c149afbf4c8996fb7ae41e4649b934c991b7852b855 We divide it in two parts, most significative bytes and less significative bytes. Part 1 less significative bytes: Code: 7ae41e4649b934c**991b7852b855 We calculate and store the publickeys from Code: 007ae41e4649b934c0000991b7852b855 to Code: ff7ae41e4649b934cffff991b7852b855 In this example is 2^24 publickeys (16777216 publickey) this can be done in seconds, this part is the precalculated data it can be more but all depend of how much memory do you have. now the second part: Code: e3b0c44c1c149afbf4c8996fb This part must be brute force from Code: e3b0c440000c1c149afbf4c8996fb00 to Code: e3b0c44ffffc1c149afbf4c8996fbff We need to add the remaining bytes filled as ZERO Example: Code: e3b0c440000c1c149afbf4c8996fb00000000000000000000000000000000000 e3b0c440000c1c149afbf4c8996fb01000000000000000000000000000000000 e3b0c440000c1c149afbf4c8996fb02000000000000000000000000000000000 e3b0c440000c1c149afbf4c8996fb03000000000000000000000000000000000 ... e3b0c44ffffc1c149afbf4c8996fbff000000000000000000000000000000000 We need to calculate each of those public key, this is again 2^24 public keys to be calculate. For EACH of those "TEMP PUBLICKEY" values we need to do a Public keys subtraction Code: NEW PUBLICKEY = TARGET PUBLICKEY - TEMP PUBLICKEY Now we need to compare the NEW PUBLICKEY against our precalcualted data if there is a match then we only need to concatenate or Add our partials privatekey to get the real one. Example, lets to say that the TARGET PRIVATEKEY is e3b0c441234c1c149afbf4c8996fb56ab7ae41e4649b934ccdef991b7852b855 In that case in some point our subtraction will be something like this: Code: ab7ae41e4649b934ccdef991b7852b855 = e3b0c441234c1c149afbf4c8996fb56ab7ae41e4649b934ccdef991b7852b855 - e3b0c441234c1c149afbf4c8996fb56000000000000000000000000000000000 If there is a match our privatekey will be: Code: ab7ae41e4649b934ccdef991b7852b855 + e3b0c441234c1c149afbf4c8996fb56000000000000000000000000000000000 Quote from: PrivatePerson on March 09, 2022, 07:49:11 AM maybe there are ready-made solutions NO, there is no public program that do that actually, because those examples of missing characters are unlikely to happen. Quote from: PrivatePerson on March 09, 2022, 07:49:11 AM 2. How to brute a private key with missing characters together? Is exactly the same but with the advantage that we can use BSGS at full capacity

768	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 08, 2022, 06:32:53 PM
Quote from: bigvito19 on March 08, 2022, 02:47:29 PM Is the search range for BSGS n/2 right? and not like xpoint mode when you have to search the whole range? The range is the range that you specify with the -r from:to parameter or the bit range with -b bit Quote from: bigvito19 on March 08, 2022, 02:47:29 PM I have 2 questions if my keys is 0 is it still generating keys or what? I know about using a lot keys slows the speed down The program should work fine the problem with the speed of 0 keys/s is because the number of key already scanned only get update when the BSGS process end one cycle complete with all the publickeys depending of your CPU speed, RAM bus, and number of publickey it may take a lot of time in some cases but the speed should be good. Recomendations: - Don't use SWAP memory - Don't use Virtualized OS - Don't use windows version

769	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 07, 2022, 05:57:15 PM
Quote from: bigvito19 on March 07, 2022, 01:54:51 PM Where or who has the BSGS that can search for multiple public keys? Check my tweet: https://twitter.com/albertobsd/status/1491653063882383362 I tested One million of publickey with a speed of 40 Gigakeys/s with only 4threads and 22 Gigabytes of RAM used

770	Bitcoin / Development & Technical Discussion / Re: the same r and the same s but another xpubkey	on: March 05, 2022, 01:12:53 PM
Quote from: Sansa_Stark on March 05, 2022, 07:38:29 AM yes, but we are not talking about r , but about diff in 2 pubkeys with the same r:) I think that you have NO idea of what are you doing. Well is not the same thing yes I agree with that, but the mathmatics behind what are you trying to do is exactly the same. The things that I wrote still apply because you have new different variables that is why you can't mix those equations. if you do it, any results that you get will be wrong. Quote from: garlonicon on March 05, 2022, 08:39:58 AM See? You have two new variables for each equation, so you always have one more variable than equation. That means, from algebraic point of view, it has many solutions. For example, assign k=1, you will get some solutions for d1 and d2. Assign k=2, you will get completely different solutions. The same for assigning d-values above. Exactly

771	Bitcoin / Development & Technical Discussion / Re: the same r and the same s but another xpubkey	on: March 05, 2022, 04:41:44 AM
Quote from: Sansa_Stark on March 02, 2022, 03:08:00 PM but is there any possibility to found "K" as nonce? NO because the equations are not solvable in that way. This is basic algebra, think in this. Code: private key = r^-1(ks -z) mod N if you have same r for two different signatures with the same private* key the equation is solvable because you have Code: private key = (r[sub]1[/sub]^-1)(k[sub]1[/sub]s[sub]1[/sub] -z[sub]1[/sub]) mod N private key = (r[sub]2[/sub]^-1)(k[sub]2[/sub]s[sub]2[/sub] -z[sub]2[/sub]) mod N in the equations above the original private key is the same so you can eliminate the privatekey element of the equation and found the K (nonce) value (r₁^-1)(k₁s₁ -z₁) =(r₂^-1)(k₂s₂ -z₂) is like Code: a = bc a = de hence you can eliminate a and do bc = de most of the equations to solve the k nonce with the repeated R value come from that premise. So how you have different Privatekeys for every transaction you can't do those eliminations. Repeat this is basic Algebra.

772	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 03, 2022, 04:15:05 PM
Quote from: PawGo on March 03, 2022, 08:25:59 AM I think PrivatePerson is referring to that topic: https://bitcointalk.org/index.php?topic=5385235.0 Wow i never heard about it, 30 missing characters and no publickey. 16^30 = 1329227995784915872903807060280344576 That is 120 bits complexity, and there is no publickey available. Please Forget that puzzle is infeasible. We still can't solve Puzzle 64 bits (this is 16 missing characters) Quote from: PawGo on March 03, 2022, 08:25:59 AM For sure any gap is a complication and I think brute-forcing the key from puzzle requires a dedicated program, relying on existing solutions requires too many additional assumptions. I agree with that, that kind of missing distribution require a specialized program.

773	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 02, 2022, 11:04:09 PM
Quote from: bigvito19 on March 02, 2022, 10:52:41 PM I wanted to know 2^24 precalculated keys, is that the maximum precalculated keys that would fit in the hashtable/bloomfilter or could you add more than that? The only limit is the RAM, near 28-29 bits per element in the bloom filter and some 10 bytes per item in an Array to do binary search, this is near to 14 bytes per item in total. I say 24 bits of precalculated data and 24 for cracking because the way that the missing characters are distributed in the user example: Code: e3b0c44**c1c149afbf4c8996fb7ae41e4649b934c991b7852b855 My idea is precalculate this part: 7ae41e4649b934c****991b7852b855 and just brute force the second. if all the missing characters were together then it can be solved with BSGS in seconds

774	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 02, 2022, 09:17:45 PM
Quote from: PrivatePerson on March 02, 2022, 09:02:32 PM I correctly understood that everything that you wrote about the division of the private key and the use of the BSGS is only subject to a known public key? Yes, all those things I wrote before are only possible with the public key. Without it there are not shortcuts or math tricks. Regards!

775	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: March 01, 2022, 06:04:58 PM
Quote from: DeepComplex on January 26, 2022, 10:25:23 PM Any updates on the additional features for Keyhunt? Not yet sorry. Quote from: PrivatePerson on February 24, 2022, 04:54:43 AM is it possible to add an option to search for lost characters in the private key? I've thinking in this for a while, but i think that it will be a better option make new program for that. Since there are different cases for every kind of places where the missing are (together or not) ending, beggining middle, publickey available or not, it is a lot of work. Quote from: PawGo on February 24, 2022, 07:17:41 AM All depends on number of missing characters. 12 like in your example is already a serious amount of work. I agree with that 12 missing characters is a lot of work. And more if there are in different part of the key. Quote from: PrivatePerson on February 24, 2022, 04:54:43 AM Private key 5KYZdUEo*3FPrtuX2QbnNP5zTd7yyr2S***sBCnWjss or 58^12 = 1449225352009601191936 Quote from: PrivatePerson on February 24, 2022, 04:54:43 AM e3b0c44c1c149afbf4c8996fb7ae41e4649b934c991b7852b855 16^12 = 281474976710656 The second key is more solvable that the first one. By the way that kind of examples are rare to be found and most of then are not real. Quote from: PrivatePerson on February 25, 2022, 07:27:13 AM Perhaps the creator of the keyhunt knows faster algorithms. With the publickey avaiable for this example we can use BSGS to do this task but we need some changes becasuse we need to do the calculate the differents ranges for each different change in the most significan bytes. To solve the your hexadecimal key example is only a 48 bits problem. because 16^12 = 2^48 = 281474976710656 If we do the last 2 missing bytes with BSGS the problem can be reduced to only a 32 bits of forcebrute, this problem can be done/solve in some hours CPU with the correct code. Edit** I found in a way to solve this (Hexadecimal key) in less than one hour, we can divide it in 2 parts a hashtable/bloomfilter of 2^24 of precalculated keys, and 24 bits of forcebrute with some math operations with publickey.

776

Bitcoin / Project Development / Re: Solving partial WIF with two missing parts

on: January 21, 2022, 10:27:07 PM

I try to find an easy/faster/efficient way to get what is the next valid WIF in this case finding the next 01 in the Encode byte, but seems that it require more operations that my current method, so i will pass that approach. PawGo if you know an easy way to calculate it please tell us.

NOW I will post here one example of what I'm doing in my program, step by step and i will show you guys the public key operations that i do to the public key in order to get a new "Transformed Public key" and how i solve the problem with that new public key.

The target public key is:

Code:

02FEE659ACF67F63F13AB4A7D676782F89EF8C51FCC9077A8709831FCEABFE261F

Lets to suppose that the only missing characters are the second chunk of 6 characters at the middle.

Code:

L1dU1111d4NTd7******6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t

I know that the key is not there, but lets to suppose that for the first example and at the end i will show you the real location and how to solve it with keyhunt. (Since you already know how to solve it with bitcrack and kangaroo).

So lets to calculate the start range and the End range for this example:

Code:

Start: L1dU1111d4NTd71111116zCyXqGyWXhXTa16dNWXZs7cpdk6en2t
Start: 808391fe958e6543b739b52db45eb396b672fc42d48472ee321f50b150cd4f8c338407d5b039

Code:

End: L1dU1111d4NTd7zzzzzz6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t
End: 808391fe958e6543b73a1667b0dbc3b3c8fe91fb939a818d5e0f8de094de4432a74307d5b039

If we remove the Encode bytes and the check sum the range in hexadecimal is:

Code:

Start: 8391fe958e6543b739b52db45eb396b672fc42d48472ee321f50b150cd4f8c33
End: 8391fe958e6543b73a1667b0dbc3b3c8fe91fb939a818d5e0f8de094de4432a7

So if we are sure that the target public key is there we can assume that the private key start by:

Code:

8391fe958e6543b7000000000000000000000000000000000000000000000000

Lets to call it "Base Private key" It's public key is:

Code:

02d1132913ea23066aeb2c862e74781cae270d06861eff13a224966dffa760a979

In that case we can substract to our target public key the value of the base publickey:

Code:

  02FEE659ACF67F63F13AB4A7D676782F89EF8C51FCC9077A8709831FCEABFE261F - 
  02d1132913ea23066aeb2c862e74781cae270d06861eff13a224966dffa760a979
= 035ba75d3476e534fc7c5f356236eac0da7a7a1285a13e2fa36725927228fa64d2

Call the Result "PublickeyStep1"

Now, as PawGo mention in this post and others of his post the problem with middle missing characters is tha they usually overwrite the encode byte 01 and others (not this case) the checksum part.

In this case the full base58 stride is:

Code:

Stride: 211111111111111111111111111111111
Hex: 0af820335d9b3d9cf58b911d87035677fb7f528100000000

If we see the hexadecimal part the last 4 bytes (8 hexadecimal characters) are 0 so in this case the Checksum is not overwritten so we can remove those not overwritten bytes and work only with the encode byte overwritten.

New Stride hex:

Code:

Hex: 0af820335d9b3d9cf58b911d87035677fb7f5281

So, to work with our actual public key "PublickeyStep1" we need to add to it one extra byte, this can be done multiplying it by 256

Code:

  035ba75d3476e534fc7c5f356236eac0da7a7a1285a13e2fa36725927228fa64d2 x 256
= 03813771bcfdb1f531273698c62adb3ed1a02693cf53e9ed1358350e8bf3ded880

Call the Result: PublickeyStep2
Also we need add 1 to the PublickeyStep2 because we expected that the valid Target (Unknow Private key) have an 0x01 value in the Encode byte

Code:

  03813771bcfdb1f531273698c62adb3ed1a02693cf53e9ed1358350e8bf3ded880 + 1
= 02019eedafe6ffa5ccc19cbc2d547edadfcfc2dc1cd1cc096794e9c2ebbbd994a3

Call the Result: PublickeyStep3

Now with that extra byte set to ONE we can work with the current stride.

You remember that we substract to the target publickey the "Base Public key" value? well now is time to subtract to the "PublickeyStep3" the value of the remainder of the of the base publickey in this case is the value of:

Code:

0x39b52db45eb396b672fc42d48472ee321f50b150cd4f8c3384

Please check the value include the extra encode byte, but with the overwritten value 0x84

Code:

  02019eedafe6ffa5ccc19cbc2d547edadfcfc2dc1cd1cc096794e9c2ebbbd994a3 - 
  03ef6c26cb9ebf5f81b80fa255602eeb5f721dd5b7d8504aa506bf010f56adcf9f
= 0361835cf65529916765ac4a5830f0ce0896312b5c0ab32e565cef0b3d0e6212a7

Call the result PublickeyStep4, I know, is getting a little complicated to follow, but it is only because the results are publickey in a ECC Operations and those operations are not in our day to day.

Now if the partial WIF is valid, I can guaranty you that the "PublickeyStep4" is perfectly divisible by our stride.

Code:

  0361835cf65529916765ac4a5830f0ce0896312b5c0ab32e565cef0b3d0e6212a7 / 0x0af820335d9b3d9cf58b911d87035677fb7f5281
= 033ba345c9f89c2a1e86c40838afd672ba691da3ca82fd47765ca645d3422026f5

This result is now our Expected "Transformed Public key" and it will be in the range from 1 to 58^6
1 to 38068692544 or in hexadecimal from 0x01 to 0x08DD122640 that is 36 bits and it can solve instantly with almost all the programs mentioned above.

Summary:
PublickeyStep1 = Target Public key - Base Public key (This last value change if we change the original first 4 missing characters)
PublickeyStep2 = PublickeyStep1 x 256 (This part add and extra "blank byte to the current public key")
PublickeyStep3 = PublickeyStep2 +1 (We add the public key of G to the current public key)
PublickeyStep4 = PublickeyStep3 - Base Public key remainder with extra overwritten byte
Transformed Public key = PublickeyStep4 / Stride

Real example:

Code:

Partial WIF: L1dUm2Fzd4NTd7******6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t
Start
L1dUm2Fzd4NTd71111116zCyXqGyWXhXTa16dNWXZs7cpdk6en2t
808393b7c5abb73dc94b37951701bc29da3d749d904321915bc2c7d71ca89579c38407d5b039
End
L1dUm2Fzd4NTd7zzzzzz6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t
808393b7c5abb73dc94b98cf137ecc46ecc90a564f59303087b3050660b98a20374307d5b039

Base privatekey key: 8393b7c5abb73dc9000000000000000000000000000000000000000000000000
Base public key: 03ffc5e2fa8ec2ecee2a15750c511cc41af6aa0756064b67665de1f7934af222de
---
PublickeyStep1 = Target Public key - Base Public key
  02FEE659ACF67F63F13AB4A7D676782F89EF8C51FCC9077A8709831FCEABFE261F - 
  03ffc5e2fa8ec2ecee2a15750c511cc41af6aa0756064b67665de1f7934af222de
= 02bafc4682ea5e3ffdf3eef19627431f06db48551ee56c6e462bca82f88d4a9e89
---
PublickeyStep2 =  PublickeyStep1 x 256
  02bafc4682ea5e3ffdf3eef19627431f06db48551ee56c6e462bca82f88d4a9e89 x 256
= 02cb57cc0aed672511bfb34bb987f64d5037d3230d66929fdc1ccb012ea142cc18
---
PublickeyStep3 =  PublickeyStep2 + 1
  02cb57cc0aed672511bfb34bb987f64d5037d3230d66929fdc1ccb012ea142cc18 + 1
= 029374d087692b29b2016b78a8a50d1ac107375dc6965dfccd4f342fb675ba63c5
---
PublickeyStep4 =  PublickeyStep3 - Base Public key remainder  with overwritten byte ( 0x4b37951701bc29da3d749d904321915bc2c7d71ca89579c384 )
  029374d087692b29b2016b78a8a50d1ac107375dc6965dfccd4f342fb675ba63c5 - 
  03e0077463f9bc522a079599ddc934743dab4b8bebfb6fdd045fd776633426096d
= 039601bb5d5f6549fe2edf8638e749f43a5ef4b70408afcb4f7a2dd163574efb02
---
Transformed Public key = PublickeyStep4  / Stride
  039601bb5d5f6549fe2edf8638e749f43a5ef4b70408afcb4f7a2dd163574efb02 / 0x0af820335d9b3d9cf58b911d87035677fb7f5281
= 03d5a61365f2e219a34e93632c29b85694f4a3847cefccd45858d45a364f0423f8

Now we find the Transformed Public key with any of our tools in the range from 0x01 to 0x08DD122640

Code:

albertobsd $ time ./keyhunt -m bsgs -f target.txt -q -r 1:1000000001 -S -n 0x100000000
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] Quiet thread output
[+] Mode BSGS secuential
[+] Opening file target.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x1
[+] -- to   : 0x1000000001
[+] N = 0x100000000
[+] Bloom filter for 65536 elements : 0.88 MB
[+] Bloom filter for 2048 elements : 0.88 MB
[+] Bloom filter for 64 elements : 0.88 MB
[+] Allocating 0.00 MB for 64 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_65536.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_2048.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_64.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_64.blm .... Done!
[+] Thread Key found privkey 61111eefd
[+] Publickey 03d5a61365f2e219a34e93632c29b85694f4a3847cefccd45858d45a364f0423f8
All points were found

real    0m0.181s
user    0m0.139s
sys     0m0.008s

In case of found one of those public keys you only need to do the inverse Operations in reverse way in order to get the Target privatekey

PrivatekeyStep4 = Transformed Privatekey x Stride
PrivatekeyStep3 = PrivatekeyStep4 + Base Private key remainder with extra overwritten byte
PrivatekeyStep2 = PrivatekeyStep3 - 1
PrivatekeyStep1 = PrivatekeyStep3 / 256
Target Privatekey = PrivatekeyStep1 + Base Private key

Code:

0x61111eefd x 0x0af820335d9b3d9cf58b911d87035677fb7f5281
= 0x428c000f436b8bde1ab3c9ff2ed9147a23571758f719777d

0x428c000f436b8bde1ab3c9ff2ed9147a23571758f719777d + 0x4b37951701bc29da3d749d904321915bc2c7d71ca89579c384
= 0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b01

0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b01 - 1
= 0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b00

0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b00 /  256
= 0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b

= 0x4b7a211710ff95661b8f515a42506a703ceb2e34018c933b + 8393b7c5abb73dc9000000000000000000000000000000000000000000000000
= 0x8393B7C5ABB73DC94B7A211710FF95661B8F515A42506A703CEB2E34018C933B

Obviously this need to be automatically to avoid errors, also remember that the first missing part is 4 characters length, this mean that we need to repeat all those operations almost 58^4 times this is 11316496 times

777	Bitcoin / Project Development / Re: Solving partial WIF with two missing parts	on: January 19, 2022, 02:01:20 PM
Yes you are right, seems if i implement the correct increment i can solve this in less than half hour with CPU even less i need to make some test L1dU1111d4NTd71111116zCyXqGyWXhXTa16dNWXZs7cpdk6en2t 80 8391fe958e6543b739b52db45eb396b672fc42d48472ee321f50b150cd4f8c33 84 07d5b039 L1dU1111d4NTd7zzzzzz6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t 80 8391fe958e6543b73a1667b0dbc3b3c8fe91fb939a818d5e0f8de094de4432a7 43 07d5b039 I'm solving the 6 missing chars with BSGS and that part is solved instantly and doesn't matter if the byte encode is over written or not, but maybe i can do that part faster with your hint

778	Bitcoin / Project Development / Solving partial WIF with two missing parts	on: January 19, 2022, 06:56:05 AM
Well i want to open this topic to ask and share a little of my experience with this kind of "edge/estrange" cases of WIF with missing characters. Example: Code: Partial WIF: L1dU**d4NTd7****6zCyXqGyWXhXTa16dNWXZs7cpdk6en2t Publickey: 02FEE659ACF67F63F13AB4A7D676782F89EF8C51FCC9077A8709831FCEABFE261F With an Public key Available my approach will be the next - Brute force all the first 4 missing characters - Calculate the the second part (6 Missing characters) with BSGS - Use a mixed mode (Brute force / BSGS ) to solve all parts together. For the user PawGo maybe this will be your Hybrid method with some changes ( Not this case in specific, but maybe some ideas on it). Question: How fast this can be solved for the public programs with CPU? I made a small script SINGLE-thread with a lot of possible improvements, the program solve this in some 3 hours, it is not a general program it need to be adapted to each case. Note: 10 11 and 12 Missing characters together in the same part at the beginning can be solved in minutes with CPU if you have the public key, without it is an impossible task. Maybe I'm missing something and this specific problem/case can be solved more easily or faster but I don't know.

779	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: January 08, 2022, 01:21:16 PM
Quote from: cryptoQueez on January 07, 2022, 05:48:30 AM Great information to share!! How to use pfile?? Why quote all the post ?? Why not just to ask that? The pfile is obsolete right now, the new version generate his own files automatically if you use always the -S option. Regards!

780	Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports	on: January 05, 2022, 12:26:17 AM
Quote from: mausuv on January 01, 2022, 02:27:10 PM hi albert @cixegz this user question https://bitcointalk.org/index.php?topic=5379443.msg58874670#msg58874670 its posible algebra and math tricks use to guess y odd is small or big range y even is small or big Roll Eyes range No there is no way to do that...

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 »