Are those private keys which generate an address, distributed randomly in 2^256 range? or they have certain numerical distances?
There is no link between the distance between two private keys and the addresses they generate. 
Topic: total bitcoin address 2^160 or 2^160/2 (Read 285 times)
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.
Are these similar privatekeys have certain distances from each other?
What do you mean by saying “similar private keys” and “distances”?
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. 
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.
Are these similar privatekeys have certain distances from each other?
What do you mean by saying “similar private keys” and “distances”?
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 Fp the finite field of secp256k1.
I updated my post.
Are these similar privatekeys have certain distances from each other? or they are random in the whole range?
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 Fp the finite field of secp256k1.
I updated my post.
Quote
I'll show you how detailly and decimally how many private keys can create the same address. So there are 2256-232-977 valid private keys. That's:
Code:
115792089237316195423570985008687907853269984665640564039457584007908834671663
Total combinations of a 160-bit number are 2160 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.
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 2160 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.
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?
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?
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
(2^256 - 232 - 977) / 2^96 is 2^160.
Log(2^256 - 232 - 977 / 2^96 )/Log(2) = 160 => 2^160
Quote
You mean how many private keys give the same compressed address? As said, approximately 2256 / 2160 = 296. 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?
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 2160 different combinations. It's the range of public keys that is ALSO around 2256. If the range of public keys was not this, but something like [1, 10], there could only be 10 different SHA256 hashes; not ~2256. Thus, the total addresses would be 10.So there can be collisions for one address (conclusion) in the range of 2^96, according to the birthday paradox.
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 2256 / 2160 = 296. That's true for uncompressed addresses too.
There are slightly less than 2256 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 2160 possible legacy addresses, and so on average 296 private keys per address.
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 2160 possible legacy addresses, and so on average 296 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.
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?
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?
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
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.
Actually it would be 2^256/2 compressed 2^128 and uncompressed 2^128
The total compressed public keys are 2256 - 232 - 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, 2256/2 isn't 2128 + 2128, but rather 2255.
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
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.
No.
There are 2160 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.
There are 2160 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.
Jump to: