Topic: Keyhunt - development requests - bug reports - page 22. (Read 15202 times)

No there is no way to do that...

Keyhunt searches the whole range in pub2rmd mode. It searches in the range given in the link I shared above.

He already has that, its called pub2rmd mode its under Experimental modes

https://github.com/albertobsd/keyhunt#pub2rmd-mode

hi albert
@cixegz this user question https://bitcointalksearch.org/topic/m.58874670
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

Thank you for posting your idea!

but this idea is really rare to success and to happen, and it takes a lot of time to do searching in a such huge range space. We need a better algorithm to target public keys.

I just know little python and I did something like this:  https://github.com/sezginyildirim91/keysubtracter

If it is adapted to the C language, it can be very productive.

Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68?
if we get the publickeys, the puzzles would be solved in less than minute.
Thanks in advance.

https://github.com/albertobsd/keyhunt/discussions/142


Yes that will be nice, the problem for that is that if I change some behavior in the main cycle of the process i will need to edit all those separate functions.


There are already stride, but it is not working properly i need to fix it.
BTW there are not stride for BSGS.

Alberto,
Is there any road map for the project? Do you want to focus on new features or do you prefer to focus on improving performance of the existing code?
What about splitting code to avoid unnecessary ifs/switches?
Any plans to introduce stride?

You keep hearing different opinions because people have different understanding of public key. If someone assumes that wallet address itself is public key he will tell you that the key space is 2^160 remaining are just collisions. But if your are talking about actual public key then you have to search in the space of 2^256 to find a private key. If you are randomly using a public key in BSGS mod then the key space is 2^256. Here is the tradeoff if your using BSGS the speeds are in typpical pkeys/sec but the range is too large and a good ram will help you. But if you are hasing the public key to ripemd-160 the typical speed is mkeys/sec a good GPU will help you. But BSGS is best for solving puzzle. And about the luck part no offense but you are not understanding the odds, if you think you are that lucky pick up a rock outside your house and it will turnout to be a meteorite in which case you will earn millions.
-- by the way this is my understanding of bitcoin if i am wrong please correct me i am eager to learn

For puzzle ranges are coming one by one and each range is bigger (wider?). But you do not launch search from the beginning (key=1), but in the specific range, which is in fact result of previous ranges.

#120: private key is between 2^119 and 2^120 - 1
...
and the last key
#160: private key is between 2^159 and 2^160 - 1

Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120?

No, i mean the other thing that you said after:

Did you mean "one private key may generate two different addresses, depending which public key is used"?

All we may talk about are only numbers, and that's true that using hash which may produce maximally 2^160 results limits somehow the number of addresses. BUT: nowadays we do not have power to try each of them. We know there are collisions, but we cannot USE them.
And that's true that one private key produce public key which may be used in any of two forms, and that's true that it would be possible that uncompressed public key from one priv key generates the same address as compressed pubkey from another priv key. But we have only assumptions, no tools.

If one day we would create addresses based on other transformation of public key, we would be in completely different situation.

One remark - people have problems with exponentiation, as it is not in common use in every day life. We add, multiply... But in general it is no obvious to understand what is the difference between 2^10 and 2^11 comparing to 2*10 and 2*11.
And then to realize the difference between 2^60 and 2^64...

In theory there are 2^96 privatekeys for each bitcoin address. Yes! that is correct. And each one of those 2^96 private keys will generate a different publickey but all those 2^96 publickeys will generate the same rmd160 hash.

Also one address can be generated from compressed or uncompressed publickey

But actually no one has ever found one example.


All addresses of bitcoin exists only 1 TIME from the range... there are no proof of that "ONLY ONE TIME..." maybe yes but repeat there is no proof of that.

There are the possibility that one address have 1 or more private keys under the range of 2^0 to 2^160
If my previous sentence is correct then that means that there are ranges of 160 bits that can haven't a specific address for example the "1111111111111111111114oLvT2" hash rmd160:  0000000000000000000000000000000000000000

We haven't enough computer power to prove  or disprove that, proof of that is that the puzzle 64 is still there.


Not really because there are 2^256 publickeys different for each other so unless that publickey was under that 2^160 range, only in that case it will be found.

But we still can't solve the publickey for the puzzle 120

Times to solve the puzzle 160 at specific speeds:

Hello albertobsd i have a Questions outside and inside this awesome program that you have made.
i've been looking for correct answers for weeks, but everyone says differently so your the one who to ask, because you're a bitcoin expert here.
Questions:


So total  possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need  in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right?

==========

Another Question related:

So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct?


==========


Last Question.

Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF )  Hex-Range with  high number of  Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck)

==========

if you could answer all this three Question, then i really appreciate it!
Best regards.

please learn algebra

if you have doubt of those post, please write your doubt there NOT HERE.

@albertobsd

iknow r s1s2  value
i need z1z2 how to calculate
i read this post explain testnet ,i am not understad https://bitcointalksearch.org/topic/m.56686056
https://bitcointalksearch.org/topic/m.10669517 #read 1,3page

please explain stepy by step calulate z1z2  from bitcoin mainet or write code

Well i try to find those keys and it only found one of the first three.


Thanks for report it

---

The weird thing is that if I look for the next publickeys it found all: