<blockquote>
  <p>The public key is first SHA256 hashed and then RipeMD160 hashed. A Bitcoin address is actually an encoded hash of the public key.</p>
</blockquote>

<p>A public key is 65 bytes long (0x04 + 64 bytes public key) or 33 bytes when compressed (0x02 | 0x03 + 32 bytes public key).</p>

<p>However, why not RipeMD160 it and make it shorter? It'd become 20 bytes. Of course, it'd be great if it were shorter, an address shouldn't be long.</p>

<p>Why RipeMD160? RipeMD collision was reported in 2004 (<a href="https://eprint.iacr.org/2004/199" rel="noreferrer">ref</a>), so maybe NSA can also break Ripemd160? So, Satoshi decided to SHA256 hash it first and then RipeMD160 it, which means it'd be <strong>much</strong> harder for an attacker to find a preimage to steal Bitcoins.</p>

<p>TL;DR shorter addresses, as well as protection for far future's quantum computers. (Even D-Wave doesn't own a quantum computer now. It's a quantum annealer. <a href="https://coingeek.com/d-wave-quantum-computer-not-quantum-computer-experts-say/" rel="noreferrer">ref</a>)</p>

CC BY-SA 3.0
2018-03-11T13:46:42.557Z
You deserve more upvotes because of the D-Wave part
Osias Jota
CC BY-SA 3.0
2018-03-11T14:58:19.023Z
Thanks. So if I understand your reply correctly... Even though P2PKH scripts take up more space in the blockchain, it's worth it for future-proofing against quantum computers?
inersha
CC BY-SA 3.0
2018-03-12T04:22:23.503Z
@inersha Yes, one day people will be encouraged to migrate their money from old addresses to quantum-proof addresses, on that day, if you can't spend your funds (locktime, etc...) you'll have hard times about the uncertainty (Will quantum computers steal my money? Will the locktime end before quantum computers crack my addresses?) If you'll have had moved your coins to an address who've never spent (in other words, public key is not revealed), you can be sure that your coins are safe (at least for 10-20 years after then). But that will happen at least 10years later,so it'snotneededcurrently
MCCCS
CC BY-SA 3.0
2018-03-12T04:27:29.150Z
And no, P2PKH saves blockchain's space. When sending to a P2PKH address, you're sending to a 20 byte hash (+1 byte OP_HASH160) instead of 33 or 65 bytes.
MCCCS
CC BY-SA 3.0
2018-03-12T12:33:21.850Z
@MCCCS But with P2PKH, don't you have to provide the (publickey + signature) when you come to spend it anyway? Whereas with P2PK you only have to provide the (signature) when you spend, so P2PK saves space overall?
inersha
CC BY-SA 3.0
2018-03-12T13:39:32.413Z
@inersha If it's going to be spent, as you said, P2PK is more compact overall.
MCCCS
CC BY-SA 3.0
2018-03-11T12:56:00.187Z
2018-03-11T14:07:46.400Z
2018-03-11T14:07:46.400Z
MCCCS
<blockquote>
  <p>what's the reason for hashing our public key for use in P2PKH?</p>
</blockquote>

<p>There is no link to ECDSA, besides that a priv key generates a pub key. But in the transaction, you would see the signature and the pubkey. So here we are talking more privacy (not ECDSA security). If a tx appears with a "pay to public key", then the tx spending script looks like this:</p>

<pre><code>ScriptPubKey= &lt;Public Key&gt; OP_CHECKSIG
ScriptSig= &lt;Signature&gt;
</code></pre>

<p>whereas P2PKH uses this:</p>

<pre><code>ScriptPubKey= OP_DUP OP_HASH160 &lt;Public KeyHash&gt; OP_EQUAL OP_CHECKSIG
ScriptSig= &lt;Signature&gt;&lt;Public Key&gt;
</code></pre>

<p>In the first example you can see the used public key when the transaction is generated (in the ScriptPubKey field). Miners would use such type of tx alot. In the P2PKH tx you see the pubkey only when it is spent. </p>

<p>Also note the difference on the spending condition, adding a layer of security. The stack executes the script of the ScriptPubKey, by copying (<code>OP_DUP</code>) the last item on the stack (<code>&lt;Public Key&gt;</code>). This public key is then hashed (<code>OP_HASH160</code>), and checked (<code>OP_EQUAL</code>). This means, when you want to spend this transaction, you have to show, that you can convert your public key (in the ScriptSig) to the same hash, as the sender put as reference in the tx (the pubkey hash). As hashes are a one way function, this is not reversible, and you cannot "steal" transactions. Imagine ECDSA was somehow broken, then hashing is not yet broken... You might be able to sign a tx, but you would still have to provide the correct hash. That is as per today's knowledge impossible. Though with broken ECDSA all other weird things might happen...   </p>

CC BY-SA 3.0
2018-03-11T15:00:13.683Z
Thanks. So to summarize, do we primarily use P2PKH so that there's no link to ECDSA, because ECDSA security is not reliable enough?
inersha
CC BY-SA 3.0
2018-03-11T20:59:41.200Z
No, ECDSA is only used for key handling, to generate priv and public keys. Primary use case for P2PKH? See Pieter's response :-)
pebwindkraft
CC BY-SA 3.0
2018-03-11T14:04:57.703Z
2018-03-11T14:04:57.703Z
pebwindkraft
<p>The original reason why addresses were a public key hashes is something you'll need to ask Satoshi. My guess however is that it was just shorter and more convenient (note that compressed public keys weren't known at the time).</p>

<p>When compressed public keys were discovered it was simply easier to stick to the existing address scheme (it didn't require any changes at all; wallet and node software happened to already support compressed public keys). Introducing a new address scheme that was both more expensive for the sender (34 bytes of output script rather than 25) would have been nearly impossible to convince the ecosystem of - knowing that deployment of P2SH even took several years.</p>

<p>One often repeated argument in favor is quantum resistance. I believe this is besides the point. We have no idea what the characteristics of a hypothetical machine relying on yet to be invented technology will be. Given the degree of key reuse on the network (so there are addresses with known public keys), the existence of a system that can break ECDSA is likely a death blow to Bitcoin. A real solution to that is to prepare and have real quantum-resistant cryptography in place before it's too late. Relying on a weird hope that those hypothetical machines are somehow too slow to steal from unconfirmed transactions before they're mined is a red herring.</p>

CC BY-SA 3.0
2018-03-11T17:58:09.833Z
So even though a P2PKH will ultimately take up more space on the blockchain (`pubkeyhash |  pubkey, signature`) than a P2PK (`pubkey | signature`), the motive for hashing the uncompressed key was to make it more convenient to pass around?
inersha
CC BY-SA 3.0
2018-03-11T18:05:24.153Z
That's my guess, yes. A base58 uncompressed pubkey address would be 95 characters.
Pieter Wuille
CC BY-SA 4.0
2018-03-11T16:53:23.350Z
2020-02-18T20:16:03.083Z
2020-02-18T20:16:03.083Z
Pieter Wuille
<p>If elliptic curve cryptography is secure enough to be able to give away a public key without fear of anyone being able to calculate our private key from it, what's the reason for hashing our public key for use in P2PKH?</p>

<p>In other words, what's the benefit of a more complex system for locking and unlocking bitcoins, if a simple P2PK transaction is secure enough?</p>

<p>I'm not against extra security, but why is it not considered to be redundant?</p>

<address><p2pkh><p2pk>
Why is P2PKH used instead of the simpler P2PK?
inersha
# Why is P2PKH used instead of the simpler P2PK?

(Asked by: username_0 on 2018-03-11)

If elliptic curve cryptography is secure enough to be able to give away a public key without fear of anyone being able to calculate our private key from it, what's the reason for hashing our public key for use in P2PKH?

In other words, what's the benefit of a more complex system for locking and unlocking bitcoins, if a simple P2PK transaction is secure enough?

I'm not against extra security, but why is it not considered to be redundant?

**Tags:** address, p2pkh, p2pk


---

## 3 answers

### Answer by username_4 on 2018-03-11. Score: 22 | Accepted answer

The original reason why addresses were a public key hashes is something you'll need to ask Satoshi. My guess however is that it was just shorter and more convenient (note that compressed public keys weren't known at the time).

When compressed public keys were discovered it was simply easier to stick to the existing address scheme (it didn't require any changes at all; wallet and node software happened to already support compressed public keys). Introducing a new address scheme that was both more expensive for the sender (34 bytes of output script rather than 25) would have been nearly impossible to convince the ecosystem of - knowing that deployment of P2SH even took several years.

One often repeated argument in favor is quantum resistance. I believe this is besides the point. We have no idea what the characteristics of a hypothetical machine relying on yet to be invented technology will be. Given the degree of key reuse on the network (so there are addresses with known public keys), the existence of a system that can break ECDSA is likely a death blow to Bitcoin. A real solution to that is to prepare and have real quantum-resistant cryptography in place before it's too late. Relying on a weird hope that those hypothetical machines are somehow too slow to steal from unconfirmed transactions before they're mined is a red herring.

> **Comments:**
> **username_0**: So even though a P2PKH will ultimately take up more space on the blockchain (`pubkeyhash |  pubkey, signature`) than a P2PK (`pubkey | signature`), the motive for hashing the uncompressed key was to make it more convenient to pass around?  
> **username_4**: That's my guess, yes. A base58 uncompressed pubkey address would be 95 characters.  

---

### Answer by username_1 on 2018-03-11. Score: 6

> The public key is first SHA256 hashed and then RipeMD160 hashed. A Bitcoin address is actually an encoded hash of the public key.

A public key is 65 bytes long (0x04 + 64 bytes public key) or 33 bytes when compressed (0x02 | 0x03 + 32 bytes public key).

However, why not RipeMD160 it and make it shorter? It'd become 20 bytes. Of course, it'd be great if it were shorter, an address shouldn't be long.

Why RipeMD160? RipeMD collision was reported in 2004 ([ref](https://eprint.iacr.org/2004/199)), so maybe NSA can also break Ripemd160? So, Satoshi decided to SHA256 hash it first and then RipeMD160 it, which means it'd be **much** harder for an attacker to find a preimage to steal Bitcoins.

TL;DR shorter addresses, as well as protection for far future's quantum computers. (Even D-Wave doesn't own a quantum computer now. It's a quantum annealer. [ref](https://coingeek.com/d-wave-quantum-computer-not-quantum-computer-experts-say/))

> **Comments:**
> **username_2**: You deserve more upvotes because of the D-Wave part  
> **username_0**: Thanks. So if I understand your reply correctly... Even though P2PKH scripts take up more space in the blockchain, it's worth it for future-proofing against quantum computers?  
> **username_1**: @username_0 Yes, one day people will be encouraged to migrate their money from old addresses to quantum-proof addresses, on that day, if you can't spend your funds (locktime, etc...) you'll have hard times about the uncertainty (Will quantum computers steal my money? Will the locktime end before quantum computers crack my addresses?) If you'll have had moved your coins to an address who've never spent (in other words, public key is not revealed), you can be sure that your coins are safe (at least for 10-20 years after then). But that will happen at least 10years later,so it'snotneededcurrently  
> **username_1**: And no, P2PKH saves blockchain's space. When sending to a P2PKH address, you're sending to a 20 byte hash (+1 byte OP_HASH160) instead of 33 or 65 bytes.  
> **username_0**: @username_1 But with P2PKH, don't you have to provide the (publickey + signature) when you come to spend it anyway? Whereas with P2PK you only have to provide the (signature) when you spend, so P2PK saves space overall?  
> **username_1**: @username_0 If it's going to be spent, as you said, P2PK is more compact overall.  

---

### Answer by username_3 on 2018-03-11. Score: 3

> what's the reason for hashing our public key for use in P2PKH?

There is no link to ECDSA, besides that a priv key generates a pub key. But in the transaction, you would see the signature and the pubkey. So here we are talking more privacy (not ECDSA security). If a tx appears with a "pay to public key", then the tx spending script looks like this:

```
ScriptPubKey= <Public Key> OP_CHECKSIG
ScriptSig= <Signature>

```

whereas P2PKH uses this:

```
ScriptPubKey= OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
ScriptSig= <Signature><Public Key>

```

In the first example you can see the used public key when the transaction is generated (in the ScriptPubKey field). Miners would use such type of tx alot. In the P2PKH tx you see the pubkey only when it is spent.

Also note the difference on the spending condition, adding a layer of security. The stack executes the script of the ScriptPubKey, by copying (`OP_DUP`) the last item on the stack (`<Public Key>`). This public key is then hashed (`OP_HASH160`), and checked (`OP_EQUAL`). This means, when you want to spend this transaction, you have to show, that you can convert your public key (in the ScriptSig) to the same hash, as the sender put as reference in the tx (the pubkey hash). As hashes are a one way function, this is not reversible, and you cannot "steal" transactions. Imagine ECDSA was somehow broken, then hashing is not yet broken... You might be able to sign a tx, but you would still have to provide the correct hash. That is as per today's knowledge impossible. Though with broken ECDSA all other weird things might happen...

> **Comments:**
> **username_0**: Thanks. So to summarize, do we primarily use P2PKH so that there's no link to ECDSA, because ECDSA security is not reliable enough?  
> **username_3**: No, ECDSA is only used for key handling, to generate priv and public keys. Primary use case for P2PKH? See username_4's response :-)  

---

