user26584: Why do you hash the public key twice? Are there security benefits to abstracting away from the public key? Is it because the address can represent multiple things? I'm missing something.
Could you theoretically send bitcoins directly to the public key?

user26392: As @Murch correctly pointed out it is indeed possible to send bitcoin to either a public key or to the hash of a public key. 
The original motivation for using hashes of public keys was to shorten the size of the address. Public keys in their uncompressed form are 64 bytes long whereas RIPE-MD outputs 20 bytes (+5 bytes of checksum and version). 
Interestingly Satoshi did not know that public keys could be compressed to 32 bytes +1 bit (Why does Bitcoin support both compressed and uncompressed keys/addresses?) and thus chose hashes as a way to get compressed addresses. 
The security implications are interesting:
Unlike public keys, hash functions like SHA-256 and RIPE-MD are believed to be quantum resistant. A quantum attacker could thus efficiently retrieve the private key for any Bitcoin public key but not for a P2PKH address. However, whenever a transaction spends from a P2PKH address it reveals the public key as part of the script. 
On the other hand the total number of possible address is 2^160 whereas the total number of public keys is roughly 2^256. Theoretically this means that addresses are less secure than public keys against a brute force attack. Obviously, a brute force attack is completely infeasible for either type of address. 

user5406: Yes, you could send bitcoins directly to the public key: in fact, both Pay-to-PubKey (P2PK) and Pay-to-PubKey-Hash (P2PKH) were introduced in the first Bitcoin release.
IIRC, P2PK is still used for Coinbase transactions sometimes, today.
P2PK transactions are slightly bigger for outputs but significantly smaller for inputs.
One advantage of P2PKH is that addresses are shorter than public keys. This allows addresses to be represented with 34 characters in Base58check.
If there were a standard to present public keys in Base58check, they'd probably have 51 characters. Arguably, it is easier to type a character jumble that is only 34 characters than one that is 51 characters. 
But really, addresses get used because there is a standard for them and there is none for public keys. Why that is so, I don't know.
All credit to Pieter, who has provided the knowledge to amend my errors. ;)
Also see this related question: Why does the default miner implementation use pay-to-pubkey?

26584: <p>Why do you hash the public key twice? Are there security benefits to abstracting away from the public key? Is it because the address can represent multiple things? I'm missing something.</p>

<p>Could you theoretically send bitcoins directly to the public key?</p>
 26392: <p>As @Murch correctly pointed out it is indeed possible to send bitcoin to either a public key or to the hash of a public key. 
The original motivation for using hashes of public keys was to shorten the size of the address. Public keys in their uncompressed form are 64 bytes long whereas RIPE-MD outputs 20 bytes (+5 bytes of checksum and version). </p>

<p>Interestingly Satoshi did not know that public keys could be compressed to 32 bytes +1 bit (<a href="https://bitcoin.stackexchange.com/questions/5952/why-does-bitcoin-support-both-compressed-and-uncompressed-keys-addresses">Why does Bitcoin support both compressed and uncompressed keys/addresses?</a>) and thus chose hashes as a way to get compressed addresses. 
The security implications are interesting:</p>

<p>Unlike public keys, hash functions like SHA-256 and RIPE-MD are believed to be quantum resistant. A quantum attacker could thus efficiently retrieve the private key for any Bitcoin public key but not for a P2PKH address. However, whenever a transaction spends from a P2PKH address it reveals the public key as part of the script. </p>

<p>On the other hand the total number of possible address is 2^160 whereas the total number of public keys is roughly 2^256. Theoretically this means that addresses are less secure than public keys against a brute force attack. Obviously, a brute force attack is completely infeasible for either type of address. </p>
 5406: <p>Yes, you could send bitcoins directly to the public key: in fact, both Pay-to-PubKey (P2PK) and Pay-to-PubKey-Hash (P2PKH) were introduced in the first Bitcoin release.
IIRC, P2PK is still used for Coinbase transactions sometimes, today.</p>

<p>P2PK transactions are slightly bigger for outputs but significantly smaller for inputs.</p>

<p>One advantage of P2PKH is that addresses are shorter than public keys. This allows addresses to be represented with 34 characters in <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="noreferrer">Base58check</a>.<br>
If there were a standard to present public keys in Base58check, they'd probably have 51 characters. Arguably, it is easier to type a character jumble that is only 34 characters than one that is 51 characters. </p>

<p>But really, addresses get used because there is a standard for them and there is none for public keys. Why that is so, I don't know.</p>

<p><sup>All credit to Pieter, who has provided the knowledge to amend my errors. ;)</sup></p>

<p>Also see this related question: <a href="https://bitcoin.stackexchange.com/q/32639/5406">Why does the default miner implementation use pay-to-pubkey?</a></p>
