<p>I think there is a mix of transaction type (p2pk, p2sh, p2pkh...) and pubkeys or addresses. The addresses are generated from the hex pubkey (a cool playground here: <a href="http://gobittest.appspot.com/Address" rel="nofollow noreferrer">http://gobittest.appspot.com/Address</a>). The pubkeys  are hashed, a network Byte added, some check summing and base58check encoded. This gives me the bitcoin address of a public key. </p>

<p>In a transaction I can use different methods to transfer funds. I had replied to your <a href="https://bitcoin.stackexchange.com/questions/72184/why-is-p2pkh-used-instead-of-the-simpler-p2pk/72189?noredirect=1#comment83587_72189">other post</a> as well. So when the spending condition only requires you to present your public key and signature, then it is a p2pk transaction. The public key would be recognized by your wallet  (following the above mentioned coding scheme) as „type 1“ address. </p>

<p>If the spending condition is set to present a public key hash, then it is a p2pkh tx, and you have the std Op_Dup, Op_Hash160,... structure. </p>

<p>When having a look onto the stack, it becomes clear, what happens. The spending tx puts its sig and pubkey on stack. Then the pubkey script goes onto stack. First command is OP_Dup, so pubkey is duplicated. Then OP_Hash160 follows, hashing the pubkey. This hash is then compared with the hash of the pubkey script (in your example „1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c“), and hopefully these two match (as per the following OP_Equal). This proves, that you are the rightful person to spend the funds, cause you could proof, that you can hash your pubkey to the referenced pubkey hash. And hashing is a one way function... no one else could do this. In the last step, the signature in the transaction is verified, and with your now provided pubkey the transaction would be checked for a valid signature (OP_Checksig).</p>

<p>Hope I could shed some light in the confusion on addresses and „pay to pubkey“ or „pay to pubkey hash“ transactions :-)</p>

CC BY-SA 4.0
2019-06-23T18:27:38.950Z
Downvoted. This is very confused and does not answer the question. P2PK outputs do not require presenting a public key and a signature; only a signature. P2PKH outputs do not require presenting a public key hash and a signature; they require a public key and a signature.
Pieter Wuille
CC BY-SA 3.0
2018-03-13T07:17:58.330Z
2018-03-13T07:17:58.330Z
pebwindkraft
<p>One of the issues with encoding P2PK outputs as an address is that they can be very long. P2PK can have both compressed and uncompressed keys. Uncompressed keys are 65 bytes, which means that the resulting address would be very long. In fact, this length is probably why P2PKH exists in the first place: as a way to have short strings as addresses. So P2PK addresses could be very long and unwieldy, so not that useful.</p>

<p>But nowadays, everyone uses compressed pubkeys so length isn't much of an issue anymore.</p>

<p>Since Satoshi didn't give P2PK an address type, the reason that one has not been created since then is that no one cares to. P2PKH already does everything P2PK does, just a little bit longer. And with other improvements coming such as Taproot (which is A pay to pubkey scheme and has its own address type), there isn't a compelling reason to go through the effort of defining a standard and trying to get wallets to implement it.</p>

CC BY-SA 4.0
2020-02-19T18:37:09.163Z
2020-02-19T18:37:09.163Z
Ava Chow
<p>If I understand addresses correctly, different types of addresses are used to <strong>map to a particular locking script</strong> (scriptPubKey).</p>

<p>So based on the <em>leading character</em> of an address, a wallet will decode the address, and then form the appropriate locking script around it.</p>

<p>For example:</p>

<p><strong>P2PKH = 1address</strong></p>

<pre><code>13qWKACQWgQDwDRDoRtqUbN59bar6ousQf
OP_DUP OP_HASH160 1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p><strong>P2SH = 3address</strong></p>

<pre><code>3MmRfLoNzap2Mt8PwHqhVtxHsmdRieuXfk
OP_HASH160 dc37feb38b5a4ad4bf09bc61eea4831f85c58103 OP_EQUAL
</code></pre>

<p><strong>P2PK = n/a</strong></p>

<pre><code>n/a
031b0e8c2567c12536aa13357b79a073dc4444acb83c4ec7a0e2f99dd7457516c5 OP_CHECKSIG
</code></pre>

<p>Why is it that <strong>P2PK</strong> scripts have never been given their own address?</p>

<p>Why not give the public key in a <strong>P2PK</strong> a checksum, then base58 encode it with it's own leading character so that we can have an address for it?</p>

<address><script><p2pk>
Why don't P2PK scripts have their own address?
inersha
# Why don't P2PK scripts have their own address?

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

If I understand addresses correctly, different types of addresses are used to **map to a particular locking script** (scriptPubKey).

So based on the *leading character* of an address, a wallet will decode the address, and then form the appropriate locking script around it.

For example:

**P2PKH = 1address**

```
13qWKACQWgQDwDRDoRtqUbN59bar6ousQf
OP_DUP OP_HASH160 1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c OP_EQUALVERIFY OP_CHECKSIG

```

**P2SH = 3address**

```
3MmRfLoNzap2Mt8PwHqhVtxHsmdRieuXfk
OP_HASH160 dc37feb38b5a4ad4bf09bc61eea4831f85c58103 OP_EQUAL

```

**P2PK = n/a**

```
n/a
031b0e8c2567c12536aa13357b79a073dc4444acb83c4ec7a0e2f99dd7457516c5 OP_CHECKSIG

```

Why is it that **P2PK** scripts have never been given their own address?

Why not give the public key in a **P2PK** a checksum, then base58 encode it with it's own leading character so that we can have an address for it?

**Tags:** address, script, p2pk


---

## 2 answers

### Answer by username_3 on 2020-02-19. Score: 5 | Accepted answer

One of the issues with encoding P2PK outputs as an address is that they can be very long. P2PK can have both compressed and uncompressed keys. Uncompressed keys are 65 bytes, which means that the resulting address would be very long. In fact, this length is probably why P2PKH exists in the first place: as a way to have short strings as addresses. So P2PK addresses could be very long and unwieldy, so not that useful.

But nowadays, everyone uses compressed pubkeys so length isn't much of an issue anymore.

Since Satoshi didn't give P2PK an address type, the reason that one has not been created since then is that no one cares to. P2PKH already does everything P2PK does, just a little bit longer. And with other improvements coming such as Taproot (which is A pay to pubkey scheme and has its own address type), there isn't a compelling reason to go through the effort of defining a standard and trying to get wallets to implement it.


---

### Answer by username_1 on 2018-03-13. Score: 0

I think there is a mix of transaction type (p2pk, p2sh, p2pkh...) and pubkeys or addresses. The addresses are generated from the hex pubkey (a cool playground here: <http://gobittest.appspot.com/Address>). The pubkeys are hashed, a network Byte added, some check summing and base58check encoded. This gives me the bitcoin address of a public key.

In a transaction I can use different methods to transfer funds. I had replied to your [other post](https://bitcoin.stackexchange.com/questions/72184/why-is-p2pkh-used-instead-of-the-simpler-p2pk/72189?noredirect=1#comment83587_72189) as well. So when the spending condition only requires you to present your public key and signature, then it is a p2pk transaction. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.

If the spending condition is set to present a public key hash, then it is a p2pkh tx, and you have the std Op\_Dup, Op\_Hash160,... structure.

When having a look onto the stack, it becomes clear, what happens. The spending tx puts its sig and pubkey on stack. Then the pubkey script goes onto stack. First command is OP\_Dup, so pubkey is duplicated. Then OP\_Hash160 follows, hashing the pubkey. This hash is then compared with the hash of the pubkey script (in your example „1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c“), and hopefully these two match (as per the following OP\_Equal). This proves, that you are the rightful person to spend the funds, cause you could proof, that you can hash your pubkey to the referenced pubkey hash. And hashing is a one way function... no one else could do this. In the last step, the signature in the transaction is verified, and with your now provided pubkey the transaction would be checked for a valid signature (OP\_Checksig).

Hope I could shed some light in the confusion on addresses and „pay to pubkey“ or „pay to pubkey hash“ transactions :-)

> **Comments:**
> **username_2**: Downvoted. This is very confused and does not answer the question. P2PK outputs do not require presenting a public key and a signature; only a signature. P2PKH outputs do not require presenting a public key hash and a signature; they require a public key and a signature.  

---

