total bitcoin address 2^160 or 2^160/2

[Kostelooscoin]

hi,
for the first private key there are 2 bitcoin addresses the compressed one and the uncompressed one so there would really be 2^160/2 bitcoins addresses

[BlackHatCoiner]

No.

There are 2¹⁶⁰ combinations of a 160-bit number. The fact that you can generate the same number with two different ways does not mean that there are half of the combinations only. Instead of a prefix and the x-coordinate of the public key, you hash a prefix and both x and y coordinates.

[bigvito19]

hi,
for the first private key there are 2 bitcoin addresses the compressed one and the uncompressed one so there would really be 2^160/2 bitcoins addresses

Actually it would be 2^256/2 compressed 2^128 and uncompressed 2^128 since you're talking about the private key.

As for the address it would be 2^160/2 compressed 2^80 and uncompressed  2^80.

[BlackHatCoiner]

Actually it would be 2^256/2 compressed 2^128 and uncompressed 2^128

The total compressed public keys are 2²⁵⁶ - 2³² - 977 since there are that many private keys which give a unique compressed public key each time. Same thing for uncompressed public keys. The only thing that's different is that instead of a changing prefix, you introduce another number, which is y and is also variable.

By the way, 2²⁵⁶/2 isn't 2¹²⁸ + 2¹²⁸, but rather 2²⁵⁵.

[a.a]

hi,
for the first private key there are 2 bitcoin addresses the compressed one and the uncompressed one so there would really be 2^160/2 bitcoins addresses

Actually it would be 2^256/2 compressed 2^128 and uncompressed 2^128 since you're talking about the private key.

As for the address it would be 2^160/2 compressed 2^80 and uncompressed  2^80.

Is this some kind of quick math? 

There are only 2^160 bitcoin addresses, because ripe-md160 only gives 2^160 results. For the input of the ripe-md160 function the publickey (compressed and uncompressed makes no difference) will get hashed with sha256.

So there can be collisions for one address in the range of 2^96, according to the birthday paradox.

But this does not make the whole keyspace to be 2^128.

[davidjjones]

Hi
As I read this post, two questions came to me:

1. Is it possible that Compressed address of Privatekey_X be the same as Uncompressed address of Privatekey_Y?

2. How many private keys are in the range with the same Compressed address?

[o_e_l_e_o]

There are slightly less than 2²⁵⁶ possible private keys.
This will generate the same number of possible uncompressed public keys and the same number of possible compressed public keys.
However, it is incorrect to consider an uncompressed and a compressed public key with the same x coordinate as two different public keys. They are the exact same point on the curve. All that is changing is how we express that point.

There are 2¹⁶⁰ possible legacy addresses, and so on average 2⁹⁶ private keys per address.

1. Is it possible that Compressed address of Privatekey_X be the same as Uncompressed address of Privatekey_Y?

Yes. For an address to match two private keys, all that is required is that there is a collision on either the SHA256 or the RIPEMD160 when turning the public key in to an address. This could potentially happen with any combination of compressed and uncompressed public keys.

[BlackHatCoiner]

For the input of the ripe-md160 function the publickey (compressed and uncompressed makes no difference) will get hashed with sha256.

So there can be collisions for one address (conclusion) in the range of 2^96, according to the birthday paradox.

Just to mention something significant: It's not the fact that the public key gets hashed with SHA256, which will give a 256-bit number as a result, the reason why there on average 2¹⁶⁰ different combinations. It's the range of public keys that is ALSO around 2²⁵⁶. If the range of public keys was not this, but something like [1, 10], there could only be 10 different SHA256 hashes; not ~2²⁵⁶. Thus, the total addresses would be 10.

2. How many private keys are in the range with the same Compressed address?

You mean how many private keys give the same compressed address? As said, approximately 2²⁵⁶ / 2¹⁶⁰ = 2⁹⁶. That's true for uncompressed addresses too.

[davidjjones]

You mean how many private keys give the same compressed address? As said, approximately 2²⁵⁶ / 2¹⁶⁰ = 2⁹⁶. That's true for uncompressed addresses too.

When you say approximately 2^96 !
then maybe there are more (or less) than 2^96 privatekeys for some addresses?

Is the number of pubkeys the same?

[a.a]

The amount of pubkeys is like the amount of privatekeys:  2^256 - 232 - 977

(2^256 - 232 - 977) / 2^96 is 2^160.

Log(2^256 - 232 - 977 / 2^96 )/Log(2) = 160 => 2^160

[Kostelooscoin]

a program to crack a private key.
this program will first target the first key 0000000....1
and will announce a compressed address and the other not compressed for only one result thus the total number of chance to crack 1 private key this is thus divided by 2. logical not?

[BlackHatCoiner]

then maybe there are more (or less) than 2^96 privatekeys for some addresses?

I'll show you detailly and decimally how many private keys can create the same address. So there are that many keys:

Code:

115792089237316195423570985008687907852837564279074904382605163141518161494336

Total combinations of a 160-bit number are 2¹⁶⁰ which is:

Code:

1461501637330902918203684832716283019655932542976

So, each address should averagely have the division of those two numbers;

115792089237316195423570985008687907852837564279074904382605163141518161494336 / 1461501637330902918203684832716283019655932542976

That's:

Code:

79228162514264337593543950336

Each time you spend bitcoins from one of your addresses, you're signing using 1 of the 79,228,162,514,264,337,593,543,950,336 different and valid, on average, private keys.

[davidjjones]

I'll show you how detailly and decimally how many private keys can create the same address. So there are 2²⁵⁶-2³²-977 valid private keys. That's:

Code:

115792089237316195423570985008687907853269984665640564039457584007908834671663

Total combinations of a 160-bit number are 2¹⁶⁰ which is:

Code:

1461501637330902918203684832716283019655932542976

So, each address should averagely have the division of those two numbers;

115792089237316195423570985008687907853269984665640564039457584007908834671663 / 1461501637330902918203684832716283019655932542976

That's:

Code:

79228162514264337593543950336

Each time you spend bitcoins from one of your addresses, you're signing using 1 of the 79,228,162,514,264,337,593,543,950,336 different and valid, on average, private keys.

I thought the number of valid private keys = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (decimal) ?

[BlackHatCoiner]

I thought the number of valid private keys = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (decimal) ?

My bad, thanks for correcting me!

Indeed, the keys are - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140. I confused the total private keys with - fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f - which is p and F_p the finite field of secp256k1.

I updated my post.

[davidjjones]

I thought the number of valid private keys = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 = 115792089237316195423570985008687907852837564279074904382605163141518161494336 (decimal) ?

My bad, thanks for correcting me!

Indeed, the keys are - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140. I confused the total private keys with - fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f - which is p and F_p the finite field of secp256k1.

I updated my post.

Thanks for your good explain.

Are these similar privatekeys have certain distances from each other? or they are random in the whole range?

[BlackHatCoiner]

Are these similar privatekeys have certain distances from each other?

What do you mean by saying “similar private keys” and “distances”?

[NotATether]

1. Is it possible that Compressed address of Privatekey_X be the same as Uncompressed address of Privatekey_Y?

Yes. For an address to match two private keys, all that is required is that there is a collision on either the SHA256 or the RIPEMD160 when turning the public key in to an address. This could potentially happen with any combination of compressed and uncompressed public keys.

I think you mean, it's possible but almost never occurs in practice (or, due to the astronomical size of 2^160, theoretically, either).

Are these similar privatekeys have certain distances from each other? or they are random in the whole range?

The value at the beginning of your quote is a private key (actually, the number of possible private keys - it's called N), the one at the end is the maximum value for the X and Y coordinates (called P) and has nothing to do with private keys.

[o_e_l_e_o]

I think you mean, it's possible but almost never occurs in practice (or, due to the astronomical size of 2^160, theoretically, either).

Well sure, in terms of actual probabilities we will never see an address collision. But it is theoretically possible with a mixture of compressed and uncompressed keys.

Are these similar privatekeys have certain distances from each other? or they are random in the whole range?

I think what he is asking is if private keys which would give us an address collision are similar or located a fixed distance apart. The answer to this is no, they would be randomly distributed throughout the whole range.

[davidjjones]

Are these similar privatekeys have certain distances from each other?

What do you mean by saying “similar private keys” and “distances”?

Are those private keys which have same address, distributed randomly in 2^256 range? or they have certain numerical distances?

[BlackHatCoiner]

Are those private keys which have same address, distributed randomly in 2^256 range?

It depends on how you understand randomness. We don't know the exact distance they each have, no.