Topic: Question about address generation from public key (Read 880 times)

Thanks all for the replies!

Actually yes, there might be a problem with that.  The public key is two 256-bit numbers, representing an (x,y) point on an elliptic curve.  By using the first 160 bits, you're only using a chunk of the x-value of the public key, without any of the y-value.  I can take 160 bits of x, add another 96 bits, and then likely compute a y-value on the curve that corresponds to that x-value I just created.  That gets me a new (x,y) point on the secp256k1 elliptic curve.  This isn't a replacement key because I don't have a private key for it, but it might open the door for an attacker to do some trickery, because no one can prove that point isn't a public key.  I don't know what kind of serious attack could be generated from this (if any), but I've seen some very creative attacks in my time.  This seems like added, unnecessary uncertainty to the process.    On the other hand, using the hash, every character of the final address is dependent on every bit of the public key.   Plus, it's already implemented... it's complex but it's a one-time investment to get it working.


This is not really a concern.  There's approximately 2^256 different possible public keys on any given elliptic curve.  Sure, because of the ripemd160, there's only 2^160 different addresses, but I assure you that 2^160 unique addresses is more than enough.  So while there's 2^96 identical hashes per address, the chance of two people actually creating two addresses that have the same address is still 1 in 2^160.  

For reference, in the entire time that the BTC network has been alive, with thousands of people computing billions of hashes per second... the entire network computed less than 2^70 hashes total.  2^32 billion people on earth.  We have at least 100 years before every atom in the universe needs it's own BTC address, and even then, there might be enough.

Another comment about sha256(sha256())... I don't know for sure, but I speculate that the reason for double hashing instead of single hashing is for security reasons (in general, not just for addresses).  Right now, it takes average 2^256 hashes to find an sha256 collision.  If someone finds a vulnerability that can find such a collision in 2^50 hashes, then the community might start considering it insecure.  However, since we use double hashing, that vulnerability likely only weakens BTC-hashing to 2^100 which is still plenty of security for many decades to come.

-Eto

Me neither, but it's just an opinion

In that case there will be 2^96 known pubkeys with the same address, it may be a problem

Correct.

Can't see any reason why that would be much weaker, really.

Not too sure about that, I doubt revealing part of the pubkey long in advance is a problem. But then I'm not a cryptographer familiar with ECC, so I wouldn't bet the future of a currency on it.

Dear all,

As I currently understand it, Bitcoin addresses are generated from ECDSA public keys as follows (ignoring any byte ordering issues for the moment):

address = base58(versionbyte + ripemd160(sha256(pubkey)) + hashCheck),
hashCheck = first4bytesof(sha256(sha256(versionbyte + ripemd160(sha256(pubkey)))))

where versionbyte is 0 in the real network and 111 in the test network.

Is there any technical/cryptographical reason why this has to be so complex?  In other words, would the following method for generating addresses have some serious flaw that the above method does not:

address = base58(version byte + first160bitsof(sha256(pubkey)) + crcCheck)
crcCheck = crc32(version byte + first160bitsof(sha256(pubkey)))

Or for that matter, is there any point to sha256'ing the public key to begin with?  i.e., would replacing first160bitsof(sha256(pub key)) with just first160bitsof(pubkey) do just as well?

Thanks!