Topic: Keyhunt - development requests - bug reports - page 14. (Read 11445 times)

MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS.

Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support).

It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS.

sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks

Where did I mention 50% of 2^256?  I stated that with Kangaroo you would have to complete roughly 2^129 group operations (with a DP of 0), 256 / 2 + 1 = 129. If you used a DP of 30, 256 / 2 + 1 = 129; 129 -30 = 99, so you would have to complete roughly 2^99 group ops. Far less than 2^160.  Do you understand how Kangaroo and BSGS work?

But you can find any and all keys in a 2^255 keyspace. So realistically, 128.5 group ops at DP 0, 2^98.5 group ops at DP 30, 2^88.5 group ops at DP 40...as you can see, it is exponentially faster searching for a pubkey versus possibly searching a 2^160 space for a possible collision.

Hi thanks for replying, I am aware of the fact that collisions exist and its not as simple as that first 2^160 private keys align with the RIPEMD 160 range. and sorry to correct 50% key range is 0-2^255 and remaining 50% 2^256 that's how exponential numbers work. My question was, tools like bitcrak has to search in the range of 2^160 private key space to find a collision, meaning it maynot be the same private key but can be hashed to get the same wallet address but BSGS has to search in the range of 2^256 as it calclates K from publickey. so this means it is better only for solving the puzzle and not any random wallet for which the public key is known?...
And albert0bsd your inputs are needed here.    

Interesting question, but to me, it's not as easy as one or the other. It's not black and white.

With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach.

hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods  that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.

Using xpoint mode is the slowest way to find a collision, 2^120/2^31 so of course you're not going to find anything. Use BSGS mode instead 2^60/2^31. You have to search the whole range in xpoint mode vs BSGS mode.

I don't remember exactly, but on average:

It took 5-6 hours to generate the file with keysubtructer.


Booting with keyhunt took about 3 hours.

Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?!
Also, how long did it take for the program to load all of those xpoints before it started working?

Thank you albert0bsd
I will try to read and make understand

Did BSGS have code in python so I can read the code and run a test it to make understand?

I don't quite understand what you are trying to convey. We're already looking for a ^120-bit range, how come in BSGS mode you detect a ^120-bit field as ^60-bits?

Also, loading 2 billion 700 million points in BSGS mode will not be efficient. Searching for a point with the -R option will take much longer.

Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode.

I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man.

Imagine that you have one Single operation to check if some Publickey P(x) is between some fixed range lets to say from 1 to 1M such operation will be like:


That operation doesn't exist because Public keys are hidden numbers they hide the x value (Private key)

So, what happened if you have the Cache of the first million keys, you only need to have a function that let you know if some publickey is inside of one array


to be computationally efficient, that function need to be fast O(1), There are a lot of Data structures that can do that, Hashtables, maps, bloomfilters etc, or some combinations between them.

What BSGS Do?

The first step is try to translate the P(x) to the keyspace between 1 to 1M (This amount can be changed this depends of the available memory), this operation is done by one single subtraction.

Lets to say that the value of x is 100123987


If we check for the function that value of P(123987) is in the array is_publickey_in_array(P(x),array) then the the result will be that we found the key, you only need to find what of those Million of values is your key and then just do some additions to recover the original KEY.

For the previous example imagine that you start from 1 to reach 100M you only need 100 Point Subtractions and 100 checks in the arrays, so instead of bruteforce that publickey 100 Million times you only need 100 basic operations that is why bsgs is some fast

This is a basic example, the real BSGS need some extra considerations like work with Perfect squares numbers, and also will be better if we work with Base 2 numbers like  2^Y numbers

This is an example with One million of publickeys in cache, now imagine what you can do with with some Billions of keys in your cache.

you can read more of BSGS in https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/



The -R option enable the random search, every time that one thread do a search it chose a different random number, this is EVERY single cycle one random number is chossen.

Regards!

Hi, albert0bsd

I would like to understand BSGS, Can you help to explain some methods? (I can study in detail more)
I understand kangaroos (a little some part) and understand some entropy or scalar for the Elliptic curve convert private key to public key
a lot of bitcoin and cryptography I do not yet understand clear

Hey albert0bsd,

I assume that in BSGS mode there no no such option as random changed key after a given key value searched?

Something like in VanitySearch there is -r as for random but also a value after how many searched keys the key is changed

Please guys stay on keyhunt topic, avoid any comment of those fake wifs

I think there is nothing extra, as phrutis is too stupid to develop any software. He is just a regular russian thief, he takes someone's software, copy/paste to his repo, changes name and sells like his own.
In that case he took WifSolveCuda, hardcoded ranges and removed printing data to the screen.
WIF is obviously fake, known for months, but as long as russians waste their time and electricity on that, I am fine.

Def not for  #64 or #120...not enough ranges covered and not enough firepower, for long enough.

I used a closed source for the #64 pool b/c we had 15-20 people working on it and if I would have left it open source, someone could have tweaked the code and if they found the key, kept it for themselves.

I wonder if the puzzle is real and if the letters and numbers have been deciphered correctly. It took me 10 minutes to get the second address correctly and still did not decipher it's wif, even though all characters are present LOL!

Yes exactly.

Well i actually suspect that the creator of the ''challenge'' has claimed that he lost 500 bitcoins and want us to search for him for the remaining 12 private key characters, where in reality we might actually be searching for something else,,,,, like for puzzle 64's private key!!

he might actually have lied to us and to anyone who is searching and using his closed-program they might just be searching for puzzle 64 private key for him instead of the claimed 500 bitcoins private key....

Could be that case, that we fell in trap and he is letting us search for puzzle 64 instead?

That's why he is using a closed-program, so we can't notice that we're searching for something else rather than the 500 BTC's key.

that is my suspecting only. I can be wrong though.