Currently, Bitcoin addresses and their checksums are constructed from the public key by a using repeated hashing with SHA256 and RIPEMD160. Now I understand the reasoning behind using hashing for constructing the checksum, but why wasn't just the original public key with a checksum added used? Is it just because of the shorter addresses or are there other privacy/security implications of using hashes of public keys instead of just public keys?


It's just to get shorter addresses. Regular public keys are 65 bytes long, which is much too long to be convenient. Compressed public keys are 33 bytes and could potentially be used instead of hashes, though these are a little longer than 20-byte hashes. It also seems likely that Satoshi didn't know about compressed public keys or wasn't comfortable with using them when he designed Bitcoin.

Hashes seem to help against certain attacks (some attacks against ECDSA, for example), though they also open up the possibility of other attacks (such as attacks against RIPEMD-160). It's not clear to me that they do improve security overall.

  • 13
    Satoshi didn't envision send-to-address as the normal way of doing payments either, they were something that could be used instead of send-to-IP when the recipient was offline. That said, they do help security a bit (though Satoshi may not have been aware of that either), an attacker cannot start attacking ECDSA (which has only 128-bit security) before the public key is known (and finding the public key from an address requires a 160-bit preimage). – Pieter Wuille May 9 '12 at 2:30
  • 6
    To elaborate on Pieter's comment: it may have been an intentional part of the design to strengthen the security of the network. In case of a flaw being found in elliptic curve cryptography, that would allow someone to derive the private key from the public key, someone could send their bitcoins to the hash of a newly generated 'replacement' public key of another algorithm (RSA for example) and it would be valid behaviour. Later when the network fully supports the 'replacement' algorithm the coins can once again be used, without ever being vulnerable to theft/hacking. – liamzebedee Nov 20 '13 at 10:51
  • 1
    @liamzebedee Isn't that point moot once a transaction has been made since it includes the full public key? Then again that's a strong argument for never using the same key twice, though it's impossible to stop someone from transferring funds to you... – Tobias Kienzler Jan 3 '15 at 8:39
  • As far as security goes, could one figure out the public key corresponding to someone's pubkey hash by looking at the scriptSig the first time they do a transaction? – JBaczuk Jul 18 '18 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.