may be can see Pollard's kangaroo ECDLP solver + plus new technic or mix other algorithm to solve brute-forcing better

Here is a list of all known public keys in the top 10,000 addresses that I scraped with a python script and blockchain.com's API, each address has at least $10 million worth of bitcoin. Knock yourselves out!

*Edit: here is the API for getting the public key from an address if it is known: https://www.blockchain.com/api/q/pubkeyaddr/{ADDRESS}

Each pubkey has only 1 X coordinate and 1 Y coordinate. And only 1 private key.

There are 2 pubkeys that share the same X coordinate (for each valid X coordinate) but they have different Y coordinates:

if A = (X,Y) then  B = -A = (X, p-Y)

(p =  2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1)


There are 3 pubkeys that share the same Y coordinate (for each valid Y coordinate) but they have different X coordinates:

if A = (X,Y) then B = k*A = (beta*X, Y) and C = k*k*A = (beta*beta*X, Y)

(k = 0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72  
and  beta = 0x7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee)

There are about 2^256 points on secp256k1, (to be precise n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141) and Fp (the field of the coordinates X e Y) has about the same size;

that means that about 1/3 of the all possible values of Y are valid Y coordinates (are coordinates of a point/pub key) and about 1/2 of all the possible values of X are valid X coordinates.

That's all.

Maybe we can use that as an optimization and go through all the X values, and check that (X² + 7) mod p gives a cubed number which would imply a valid Y. This would eliminate half of the search space. Similarly we can go through all the Y values and calculate Y³ mod p is a square number which implies a valid X and eliminate 2/3s of the search space.

Since the invalid points derived for each X and Y don't overlap, we have already removed 1/2 * 2/3 = 1/3 of the total possible search space like that.

That is the expected # you have to find before finding the solution, not how many x bit DPs exist in the range.

Probably a good as a guess as any. One also has to remember there are leading DPs example: 00001234 and trailing DPs, example: 12340000. There are also in between DPs, example: 12000034. I've seen all three used in different Kangaroo programs. Not sure which is best/faster to search for. If they are of the in between type, they have to line up. Example, 12000034 won't work with 10000234. All interesting.
I went through a small range 1-300FFF and didn't find any 32 DPs. I was closely looking at trailing, but I don't think there were any leading or in between either.

Anywho, if we use your 2^28, that would mean 2^28 for each type of DP, leading, trailing, and in between. So that would mean 2^29.5 (minimum, because the in between ones can be in between anywhere.)

Question to the smart people:

If one is using the kangaroo method, searching for 32 bit distinguished points, and searching in the 120 bit range, how many x coordinates (x coordinate is what the program finds of a given public key, which in kangaroo terminology means "distance traveled") would have a 32 bit distinguished point?

There are 2^120 possibilities, but we know not every private key in the 120 bit range has a public key x coordinate that has a DP of 32. Is there a good guesstimate or is it just anyone's guess?

I should clarify, how many tame points in a 120 bit range would/could have distinguished points of 32 bits?

And have you had any success with those ?

EDIT: I say too much and take too long to type. o_e_i_e_o has responded with mostly thee same response, only faster.  I'll leave this here just in case anyone finds that it adds any interest.

Because with a version 1 P2PKH address there are approximately 2²⁵⁶ unique private-public key pairs. An address is based on a RIPEMD160 HASH of the public key (actually a RIPEMD160 HASH of a SHA256 HASH of a public key) resulting in 2¹⁶⁰ unique version 1 P2PKH addresses.

2²⁵⁶ keys divided by 2¹⁶⁰ addresses equals an average of about 2⁹⁶ private keys PER address.


To find just 1 of those private keys...

• Acquire access to enough computing power to calculate addresses from 10¹⁰ private keys per second.
• Run that computing power continuously for (on average) 2.3 * 10³⁰ years

To find ALL of those private keys...

• Acquire access to enough computing power to calculate addresses from 10¹⁰ private keys per second.
• Run that computing power continuously for (on average) 1.8 * 10⁵⁹ years

Alternatively...

• Study advanced mathematics
• Become the top expert in the entire world in the mathematics related to ECDSA, SHA256, and RIPEMD160
• Discover a mathematical weakness that nobody else in the world has ever discovered related to those algorithms
• Use that mathematical weakness to calculate your private keys

Correct.


Don't bother. It's not worth the effort.  There are better systems to encrypt and decrypt messages. I believe that some have created some software to do it (with the public key, it can't be done with the address), but I wouldn't use any of it.

If every bitcoin address can be generated by 2^93 private keys, then chances of brute-forcing and finding private keys of that specific address are respectively higher?

2²⁵⁶ - 432420386565659656852420866394968145599 in hex is:
This number is the order n of the curve, and is the upper limit for a valid private key.

The number you gave on the previous page, 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ - 2⁶ - 2⁴ - 1 in hex is:
This number is the field p of the curve, which is the field of integers over which the curve is defined.

What's the URL of that site?

Is lavishness some kind of measure of how active this solution is? I don't understand why it would have an additive and a multiplicative lavishness, not to mention mining ratio which isn't even a metric in Vanitysearch.