🖤

[digaran]

🖤

[hosseinimr93]

Do we get the same private/address when we use hex value on all implementations? That means every hex can generate 2 private keys and 2 addresses ( legacy ). How can we have 2^256 compressed addresses/private keys, and have 2^256 uncompressed addresses and keys?

Due to secp256k1 ECDSA standard, the number of valid private keys is slightly less than 2²⁵⁶.
The number of valid addresses is much smaller. There are 2¹⁶⁰ valid addresses (more addresses, if we consider different types) which means that each address can be generated by 2⁹⁶ private keys on average.

[DannyHamilton]

These questions keep me up at nights.

Get some sleep. These questions aren't worth staying up over.

How many compressed addresses exist?

Assuming you are asking about version 1 legacy addresses (P2PKH addresses that start with a 1), there are effectively 2¹⁶⁰ of them.

How many uncompressed addresses exist?

Assuming you are asking about Base58Check P2PKH addresses that start with a 1, there are effectively also 2¹⁶⁰ of these.

Do we get the same private/address when we use hex value on all implementations? That means every hex can generate 2 private keys and 2 addresses ( legacy ).

Yes, every hex private key has 2 different Base58Check WIF private key representations (a representation starting with a 5 indicating that an uncompressed public key representation should be used, and a representation starting with a K or L indicating that a compressed public key representation should be used). Each of those 2 private key representations for a single private key will result in the same public key X & Y coordinates, and that public key will have 2 different representations:

• the compressed key representation that includes the 256 bit X value and an 8 bit indicator of whether the Y value is odd or even (used if the Base58Check WIF private key representation had the compressed key indicator)
• an uncompressed key representation that includes the full 256 bit X value AND the full 256 bit Y value along with an 8 bit indicator of the fact that this is the uncompressed public key representation (used if the Base58Check WIF private key representation had the uncompressed key indicator)

Each of those 2 different public key representations will have a 160 bit public key hash, and those two hashes will effectively always be different from each other (and therefore the single hex private key will have 2 different P2PKH legacy addresses).

How can we have 2^256 compressed addresses/private keys, and have 2^256 uncompressed addresses and keys?

We don't.

We have approximately 2²⁵⁶ private keys (with 2 different representations of each of those keys), for a total of approximately 2²⁵⁷ different Base58Check WIF private key representations.
We also have approximately 2¹⁶⁰ different P2PKH (legacy) addresses.

So, on average, each unique P2PKH bitcoin address has 2⁹⁶ different unique private keys, or 2⁹⁷ different unique Base58Check WIF private key representations.

And why do I keep seeing 142857 everywhere. Is 7 a constant number or something?

In what context have you seen that number?  I'm not familliar with its significance to Bitcoin discussions.

[garlonicon]

And why do I keep seeing 142857 everywhere. Is 7 a constant number or something?

If you divide one by a prime number 7, then it is not surprising, that you will get 0.(142857) as a decimal (base 10) result. In base 7, it would be simply 0.1, all digits you can get in such way, strictly depends on relation between denominator (here: 7), and a base (here: 10).

I'm not familliar with its significance to Bitcoin discussions.

It is unrelated.

[nc50lc]

This is puzzle related. How can I be certain that after searching the whole 160 bit range, I didn't miss any address/private key?
-snip-

Because the creator of the puzzle said so plus the consistencies in the solved puzzle ranges.
Because there's no way to verify that the unsolved puzzles' keys are really within that range, so it's not guaranteed by any data or math.
We only got the addresses (and some public keys) and as you know it, we can't guess the private key's range based from those information alone.

For reference, here's the puzzle creator's post: http://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941

[nc50lc]

-snip-

Thanks, I didn't mean to search for the puzzle, I mean if there are 2^160 or 2^160.8 ish addresses in total, is there any way we could skip looking in the 256 bit range, since by looking in that range will cost us power of 2^96  more computational power, which is a huge waste of resources and would take billions of years while 2^160.8 is extremely cheaper even though that would also take thousands of years.

Okay, the third sentence is still applicable to the question regardless of its relation to the puzzle.

As explained by others, there are more private keys than addresses but the possible collisions aren't grouped in a specific range,
address derived from a prvKey in 160-bit range could have a collision within the same range so we can't just excempt prvKeys from 161~256-bit in the search.
And addresses don't have a "range" or any indicator from which private key it's derived from.

[HCP]

Or put another way... they are not uniformly distributed. Given there is no mathematical proof for being able to confirm that any given range is "empty". You would need to search the entire range to be 100% you have found everything.

It's one of the fundamental concepts that provides the security of the system, by making it especially onerous in terms of computing power to be able to search everything... at least until someone travels back from the far future with really fancy quantum, or an as yet undiscovered type of, computing power and really screws up everything

[o_e_l_e_o]

What does it mean when you can change the compression flag on both X and Y coordinates to get 2 compressed public keys from X, and 2 compressed keys from Y, but you can't change an uncompressed flag to get another public key, does that mean there could be 4 times more compress keys than uncompressed keys?(I know if we change the flag we won't be able to derive the private key for the new pub keys, just wanna know.

An uncompressed public key takes the form of a 0x04 byte, followed by the 32 byte x coordinate and the 32 byte y coordinate, for 65 bytes in total.

Each x coordinate on the secp256k1 curve has exactly two possible y coordinates, one of which is even, and one of which is odd. So knowing which y coordinate your public key has, you can compress your public key to either an 0x02 byte if the y coordinate is even, or an 0x03 byte if the y coordinate is odd, followed only by the 32 byte x coordinate, for 33 bytes in total. The y coordinated can be derived from knowledge of the x coordinate and whether the y coordinate is positive or negative.

There are the same number of compressed and uncompressed public keys. There is a 1-to-1 correlation. Each uncompressed public key has exactly one compressed public key which is derived from the same private key. If you change the 0x02/0x03 byte on a compressed public key, then that corresponds to a different uncompressed public key (which happens to be derived from the original private key negated mod n).

Another question, do we need at least a 66 digits or 64 digits without the flag to turn the public key into an address or we could use any length as a public key?

The public key must be in the exact uncompressed or compressed format as I have described above. As part of the unlocking script, you must provide a valid signature for that public key. If your public key is misformed, then your signature will fail.

The reason why I'm asking this is because I have turned some random strings with different lengths into an address and I was wondering, what kind of private keys would give me those random and short public keys?

None. Every valid public key is of the format I described above.