Bitcoin Forum
May 08, 2024, 09:35:45 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Question about address generation from public key  (Read 866 times)
patvarilly (OP)
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
August 18, 2011, 07:45:33 PM
 #1

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!
1715204145
Hero Member
*
Offline Offline

Posts: 1715204145

View Profile Personal Message (Offline)

Ignore
1715204145
Reply with quote  #2

1715204145
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
ArtForz
Sr. Member
****
Offline Offline

Activity: 406
Merit: 257


View Profile
August 18, 2011, 09:11:40 PM
 #2

Quote from: patvarilly
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.
Correct.

Quote from: patvarilly
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)))
Can't see any reason why that would be much weaker, really.

Quote from: patvarilly
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!
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.

bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz
i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1233


May Bitcoin be touched by his Noodly Appendage


View Profile
August 18, 2011, 09:24:15 PM
 #3

Quote from: patvarilly
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)))
Can't see any reason why that would be much weaker, really.
Me neither, but it's just an opinion

Quote from: patvarilly
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!
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.
In that case there will be 2^96 known pubkeys with the same address, it may be a problem

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
August 18, 2011, 10:47:53 PM
Last edit: August 18, 2011, 11:14:29 PM by etotheipi
 #4

Quote
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?

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.

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

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

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
patvarilly (OP)
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
August 19, 2011, 04:26:14 AM
 #5

Thanks all for the replies!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!