<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2013-11-20T10:51:23.457Z
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
CC BY-SA 3.0
2015-01-03T08:39:41.767Z
@liamzebedee Isn't that point moot once a [transaction](https://en.bitcoin.it/wiki/Transactions) 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
CC BY-SA 4.0
2018-07-18T15:29:10.377Z
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
CC BY-SA 4.0
2021-05-20T12:02:21.233Z
@liamzebedee does it mean it's unsafe to expose our public keys?
Ilya Loskutov
CC BY-SA 3.0
2012-05-09T02:30:10.603Z
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
CC BY-SA 3.0
2012-05-08T15:36:11.337Z
2012-05-08T15:36:11.337Z
theymos
<p>Currently, Bitcoin addresses and their checksums are <a href="https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses">constructed</a> 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?</p>

<address><hash><sha256><ripemd160>
Why are Bitcoin addresses hashes of public keys?
Noah
# Why are Bitcoin addresses hashes of public keys?

(Asked by: username_0 on 2012-05-08)

Currently, Bitcoin addresses and their checksums are [constructed](https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses) 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?

**Tags:** address, hash, sha256, ripemd160


---

## 1 answers

### Answer by username_1 on 2012-05-08. Score: 32 | Accepted answer

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.

> **Comments:**
> **username_6**: 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).  
> **username_2**: To elaborate on username_6'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.  
> **username_3**: @username_2 Isn't that point moot once a [transaction](https://en.bitcoin.it/wiki/Transactions) 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...  
> **username_4**: 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?  
> **username_5**: @username_2 does it mean it's unsafe to expose our public keys?  

---

