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.

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.

The serious part is: I have a little doubt on the viability of RIPEMD160, by the curse of "birthday paradox", approaching 2^80 computation doesn't seem to be too remote.

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.

Is using intel optane persistent memory has any effect on the speed compared to the regular Dram? Has anyone tested with it ?

You are quick to judge about someone having "sane mind" or not.

I have some BTC aquired in the early days, and haven't sold almost anything until now, < 10% of it, it is far to early to sell something. BTC price is yet to go to expected values.

Those people you've mentioned have much, much more than me, and even if they've sold some small ampunt, they have absolutly no reason to move coins from other blocks at all. These stories abour lot's of BTC being lost are just legends, there were some incidents but majority of the old coins are hodled safelly in wallets, it is easy to keep the private keys safe. It is not a rocket science.

How do you know that these keys are forgotten?

Just google for 'bitcoin dust attack' and you can easily understand the reason of these transactions and why they were 547 sat

In those case you need to use a small N value, like 0x40000000 (30 bits) or 0x1000000 (24 bits)



the default N value is 0x100000000000 enough to cover some 44 bits in  a single operation using only some 1 or 2 MB of RAM


So i dont see the necessity to specify a lower range, unless you are doing some test for your self.

I have another noob question for you about the website privatekeys.pw. Why they can provide a Search Private Key queries but not Search Address? If their website able to Search Private Key, why can't they do Search Address for their pages?

Each page is only generated if visited...basically each page contains say 100 keys/addresses, so the website script knows if you visit page 900 to calculate the keys for 9000 through 9100.