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

CC BY-SA 3.0
2016-10-24T21:13:03.083Z
WIF is a format for private keys, not addresses. I also have never seen a standard for P2PK addresses.
Pieter Wuille
CC BY-SA 3.0
2016-10-24T22:02:19.767Z
@PieterWuille: Corrected WIF to Base58. I don't get your comment about "P2PK addresses"?
Murch
CC BY-SA 3.0
2016-10-24T22:15:16.880Z
You say "public keys (51 characters in Base58), but AFAIK no standard exists to encode public keys as base58.
Pieter Wuille
CC BY-SA 3.0
2016-10-24T22:17:32.457Z
@PieterWuille: Wouldn't it be the same length as a private key because it's also a 256 bit number?
Murch
CC BY-SA 3.0
2016-10-24T22:20:06.817Z
Well, yes, it would be, but that seems an irrelevant hypothetical. The biggest reason why people don't make P2PK outputs is that there is no address standard for it. You can argue why such a standard does not exist (as your answer points out, size is one reason), but you're skipping a step.
Pieter Wuille
CC BY-SA 3.0
2016-10-24T22:20:08.787Z
@PieterWuille: I guess I have too much half-knowledge. :p
Murch
CC BY-SA 3.0
2016-10-24T22:28:58.780Z
@PieterWuille Are there any other reasons?
Murch
CC BY-SA 3.0
2016-10-24T23:12:30.037Z
1) Compressed pubkeys weren't known when P2PKH address types were defined (so it'd be 95 base58 characters). 2) Higher cost to the sender. 3) Longer opportunity for hypothetical ECDLP attackers (which need to full pubkey).
Pieter Wuille
CC BY-SA 4.0
2018-06-05T21:10:50.750Z
Without checksums and prefixes a compressed pubkey is 33bytes, 45 bytes base58 encoded, vs 87 bytes uncompressed.   The ECDLP attack prevention is the best reason.   Without the pubkey, you basically have nothing to attack.
Erik Aronesty
CC BY-SA 3.0
2016-10-24T19:53:07.663Z
2016-10-24T22:28:47.243Z
2017-04-13T12:47:33.283Z
Murch
<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>

CC BY-SA 3.0
2018-04-12T13:43:10.667Z
@benehsv your response is useful but the last point your make appears to me to be false however. You say PS2PK is harder to attack than PS2PKH. I think it is the opposite. With PS2PK the length benchmark is indeed 2^256. But with BTC addresses you don't just need to crack the BTC address back into a public key (2^256), that serves no purposes unless and until you then crack the public key back into its private key input for the EC curve (2^256). So actually the length benchmark is 2^(256+160)! Hence p2pkh is way more secure and complex to crack
Rod
CC BY-SA 3.0
2018-04-18T00:10:00.673Z
@RodrigueAfota I am not sure that I agree. Say there is an address addr=H(g^(x)). The attackers goal is to find an x’ such that H(g^x’)=H(g^(x)). This x’ can be used to create a signature to spend the coins from addr This doesn’t meant that x=x’. If the RIPMD+SHA256 indeed have 160 bit security then the best attack runs in time roughly 2^160. If there are attacks on RIPMD the the best attack would be reduced (e.g. a quantum computer can do this in time 2^80). However I forgot to mention that the best classical algorithm for solving the discrete log problem already runs in time 2^128.
Benedikt Bünz
CC BY-SA 3.0
2016-10-24T22:40:44.817Z
2016-10-24T22:40:44.817Z
2017-04-13T12:47:33.743Z
Benedikt Bünz
<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>

CC BY-SA 3.0
2016-10-24T18:50:21.823Z
:/ this is not a well formed question. what are you talking about? the fact that the key is hashed?
smatthewenglish
CC BY-SA 3.0
2016-10-24T18:56:16.510Z
The fact that you hash the key twice, with SHA256 and RIPEMD160. Why go through the process? I'm working through Mastering Bitcoin, and he didn't explain very well why we need addresses.
ihtkwot
CC BY-SA 3.0
2016-10-24T19:01:02.833Z
it's it becasue it's some kind of special encoding that removes `l` and `1`, something like that, to make then easier to read
smatthewenglish
CC BY-SA 3.0
2016-10-24T19:02:17.207Z
It's just to make them easier to read? So, if that's the case, could you theoretically send bitcoin directly to the public key instead of the address?
ihtkwot
CC BY-SA 3.0
2016-10-24T19:33:38.957Z
maybe. how would you get the private key in isolation?
smatthewenglish
CC BY-SA 3.0
2016-10-24T19:55:38.423Z
@s.matthew.english: [Base58Check](https://en.bitcoin.it/wiki/Base58Check_encoding) is just an encoding to present large numbers in a more readable fashion. It can be applied to Public Keys just as it can be to addresses.
Murch
CC BY-SA 3.0
2016-10-24T23:58:19.620Z
The double hash is to protect against length-extension attacks. There's no reason to think you'd be vulnerable to such attacks, but it's a cheap way to ensure you don't even have to think about it. There is a slight security advantage in that the public key can be kept secret for longer, if desired. As stated below, Satoshi use a hash to keep the address as short as possible.
David Schwartz
<wallet><address><public-key><p2pkh><p2pk>
Why do you use Bitcoin addresses instead of public keys?
ihtkwot
# Why do you use Bitcoin addresses instead of public keys?

(Asked by: username_0 on 2016-10-24)

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?

**Tags:** wallet, address, public-key, p2pkh, p2pk

> **Comments:**
> **username_1**: :/ this is not a well formed question. what are you talking about? the fact that the key is hashed?  
> **username_0**: The fact that you hash the key twice, with SHA256 and RIPEMD160. Why go through the process? I'm working through Mastering Bitcoin, and he didn't explain very well why we need addresses.  
> **username_1**: it's it becasue it's some kind of special encoding that removes `l` and `1`, something like that, to make then easier to read  
> **username_0**: It's just to make them easier to read? So, if that's the case, could you theoretically send bitcoin directly to the public key instead of the address?  
> **username_1**: maybe. how would you get the private key in isolation?  
> **username_2**: @s.matthew.english: [Base58Check](https://en.bitcoin.it/wiki/Base58Check_encoding) is just an encoding to present large numbers in a more readable fashion. It can be applied to Public Keys just as it can be to addresses.  
> **username_3**: The double hash is to protect against length-extension attacks. There's no reason to think you'd be vulnerable to such attacks, but it's a cheap way to ensure you don't even have to think about it. There is a slight security advantage in that the public key can be kept secret for longer, if desired. As stated below, Satoshi use a hash to keep the address as short as possible.  

---

## 2 answers

### Answer by username_2 on 2016-10-24. Score: 20

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](https://en.bitcoin.it/wiki/Base58Check_encoding).  
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 username_4, who has provided the knowledge to amend my errors. ;)

Also see this related question: [Why does the default miner implementation use pay-to-pubkey?](https://bitcoin.stackexchange.com/q/32639/5406)

> **Comments:**
> **username_4**: WIF is a format for private keys, not addresses. I also have never seen a standard for P2PK addresses.  
> **username_2**: @username_4: Corrected WIF to Base58. I don't get your comment about "P2PK addresses"?  
> **username_4**: You say "public keys (51 characters in Base58), but AFAIK no standard exists to encode public keys as base58.  
> **username_2**: @username_4: Wouldn't it be the same length as a private key because it's also a 256 bit number?  
> **username_4**: Well, yes, it would be, but that seems an irrelevant hypothetical. The biggest reason why people don't make P2PK outputs is that there is no address standard for it. You can argue why such a standard does not exist (as your answer points out, size is one reason), but you're skipping a step.  
> **username_2**: @username_4: I guess I have too much half-knowledge. :p  
> **username_2**: @username_4 Are there any other reasons?  
> **username_4**: 1) Compressed pubkeys weren't known when P2PKH address types were defined (so it'd be 95 base58 characters). 2) Higher cost to the sender. 3) Longer opportunity for hypothetical ECDLP attackers (which need to full pubkey).  
> **username_5**: Without checksums and prefixes a compressed pubkey is 33bytes, 45 bytes base58 encoded, vs 87 bytes uncompressed.   The ECDLP attack prevention is the best reason.   Without the pubkey, you basically have nothing to attack.  

---

### Answer by username_6 on 2016-10-24. Score: 15

As @username_2 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?](https://bitcoin.stackexchange.com/questions/5952/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.

> **Comments:**
> **username_7**: @benehsv your response is useful but the last point your make appears to me to be false however. You say PS2PK is harder to attack than PS2PKH. I think it is the opposite. With PS2PK the length benchmark is indeed 2^256. But with BTC addresses you don't just need to crack the BTC address back into a public key (2^256), that serves no purposes unless and until you then crack the public key back into its private key input for the EC curve (2^256). So actually the length benchmark is 2^(256+160)! Hence p2pkh is way more secure and complex to crack  
> **username_6**: @RodrigueAfota I am not sure that I agree. Say there is an address addr=H(g^(x)). The attackers goal is to find an x’ such that H(g^x’)=H(g^(x)). This x’ can be used to create a signature to spend the coins from addr This doesn’t meant that x=x’. If the RIPMD+SHA256 indeed have 160 bit security then the best attack runs in time roughly 2^160. If there are attacks on RIPMD the the best attack would be reduced (e.g. a quantum computer can do this in time 2^80). However I forgot to mention that the best classical algorithm for solving the discrete log problem already runs in time 2^128.  

---

