<p>Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive <a href="https://en.bitcoin.it/wiki/IP_transaction">IP-to-IP payment protocol</a>; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.</p>

<p>Is this space savings why Nakamoto chose to use P2PK for mining and interactive payments even when he had P2PKH available, or did he have some other reason for using different transaction types?  I think only he knows.</p>

<p>In a situation where you don't need the shorter P2PKH addresses, such as mining, interactive payments, or paying to your own pubkey for change, using a P2PK may be the better option, although there is a security advantage to P2PKH if you don't reuse addresses and if ECDSA someday gets broken in a certain way that makes attacks possible but slow to execute.</p>

<pre><code>Type   Output                Input             Total Bytes
       ScriptPubKey          ScriptSig

       push ....... 1        push  ... 1
       &lt;key&gt; ...... 33       &lt;sig&gt; ... ~72
P2PK   checksig ... 1
       --------------        -------------
       Total ...... 35       Total ... ~73     ~108

       dup ........ 1        push .... 1
       hash160 .... 1        &lt;sig&gt; ... ~72
       push ....... 1        push .... 1
P2PKH  &lt;hash&gt; ..... 20       &lt;key&gt; ... 33
       equal ...... 1
       checksig ... 1
       --------------        --------------
       Total ...... 25       Total ... ~107   ~132
</code></pre>

<p>The numbers above assume that you're using a <a href="https://bitcoin.org/en/developer-guide#public-key-formats">compressed public key</a>, which are widely used today but were not implemented until <a href="https://bitcoin.org/en/release/v0.6.0">Bitcoin Core 0.6.0</a>.  If you want to consider the older "uncompressed" public keys, add 32 bytes to the <code>&lt;key&gt;</code> byte sizes.  Also, we ignore all constant factors in creating an output or input and just consider the number of bytes in the script.</p>

<p>I'm not aware of any compatibility issues---plenty of miners and mining pools use their own software to pay to P2PKH addresses, as you can see from the coinbases in recent blocks.</p>

CC BY-SA 3.0
2016-08-25T23:29:12.263Z
Is it possible, that this is information outdated? I had coffee last week with Pieter, and he calculated `PREVOUT + SCRIPTSIG = 36 + (1 + 1 + 33 + 1 + (71 or 72)) = 143 or 144`
 for the P2PKH input.
Murch
CC BY-SA 3.0
2016-08-26T20:51:16.537Z
The numbers here 1) don't include the prevout and 2) assume an uncompressed pubkey.
Pieter Wuille
CC BY-SA 3.0
2016-08-27T12:50:57.040Z
@Murch I updated the answer to use compressed pubkeys, to mention uncompressed pubkeys, and to mention what's not counted.  I believe all the calculations were (and are) correct; however, some of the historical information was wrong (as I've learned since first writing this answer) so I corrected that.  Also, I'm glad you and Pieter were able to have coffee together. :-)
David A. Harding
CC BY-SA 3.0
2014-11-20T18:04:48.833Z
2016-08-27T12:55:19.693Z
2016-08-27T12:55:19.693Z
David A. Harding
<p>Looking at the v0.9.3 source in miner.cpp:</p>

<pre><code>CBlockTemplate* CreateNewBlockWithKey(CReserveKey&amp; reservekey)
{
    CPubKey pubkey;
    if (!reservekey.GetReservedKey(pubkey))
        return NULL;

    CScript scriptPubKey = CScript() &lt;&lt; pubkey &lt;&lt; OP_CHECKSIG;
    return CreateNewBlock(scriptPubKey);
}
</code></pre>

<p>The default <code>scriptPubKey</code> is a pay-to-pubkey? Does it need to be preserved for compatibility? I'm just surprised that it's not using pay-to-pubkey-hash.</p>

CC BY-SA 3.0
2014-11-20T17:40:53.373Z
Reading the code, I agree with your assessment. Probably doesn't need to stay that way for compatibility, but I've got no clue why they did it that way.
Nick ODell
CC BY-SA 3.0
2014-11-20T18:00:37.927Z
I think P2PK was all that was used at the beginning, so I see why it started off that way, I'm just wondering why it was never changed...
morsecoder
CC BY-SA 3.0
2014-11-20T18:01:41.520Z
It's not possible to construct a P2PK from just a bitcoin address - therefore P2PKH must have existed at the beginning.
Nick ODell
CC BY-SA 3.0
2014-11-20T18:03:42.800Z
I'm not saying it couldn't have been done, just that no one used P2PKH until later.
morsecoder
CC BY-SA 3.0
2014-11-20T18:07:21.493Z
@NickODell recall that originally Bitcoin used [IP transactions](https://en.bitcoin.it/wiki/IP_Transactions), not addresses.  I'd have to check to be absolutely sure, but I don't think Bitcoin 0.1 included P2PKH.
David A. Harding
CC BY-SA 3.0
2014-11-20T18:34:50.333Z
Nevermind - [The first Bitcoin transaction was P2PK](https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16). I'm wrong.
Nick ODell
<script><bitcoin-core-development><coinbase-transaction><p2pk>
Why does the default miner implementation use pay-to-pubkey?
morsecoder
# Why does the default miner implementation use pay-to-pubkey?

(Asked by: username_0 on 2014-11-20)

Looking at the v0.9.3 source in miner.cpp:

```
CBlockTemplate* CreateNewBlockWithKey(CReserveKey& reservekey)
{
    CPubKey pubkey;
    if (!reservekey.GetReservedKey(pubkey))
        return NULL;

    CScript scriptPubKey = CScript() << pubkey << OP_CHECKSIG;
    return CreateNewBlock(scriptPubKey);
}

```

The default `scriptPubKey` is a pay-to-pubkey? Does it need to be preserved for compatibility? I'm just surprised that it's not using pay-to-pubkey-hash.

**Tags:** script, bitcoin-core-development, coinbase-transaction, p2pk

> **Comments:**
> **username_1**: Reading the code, I agree with your assessment. Probably doesn't need to stay that way for compatibility, but I've got no clue why they did it that way.  
> **username_0**: I think P2PK was all that was used at the beginning, so I see why it started off that way, I'm just wondering why it was never changed...  
> **username_1**: It's not possible to construct a P2PK from just a bitcoin address - therefore P2PKH must have existed at the beginning.  
> **username_0**: I'm not saying it couldn't have been done, just that no one used P2PKH until later.  
> **username_2**: @username_1 recall that originally Bitcoin used [IP transactions](https://en.bitcoin.it/wiki/IP_Transactions), not addresses.  I'd have to check to be absolutely sure, but I don't think Bitcoin 0.1 included P2PKH.  
> **username_1**: Nevermind - [The first Bitcoin transaction was P2PK](https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16). I'm wrong.  

---

## 1 answers

### Answer by username_2 on 2014-11-20. Score: 16 | Accepted answer

Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive [IP-to-IP payment protocol](https://en.bitcoin.it/wiki/IP_transaction); P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.

Is this space savings why Nakamoto chose to use P2PK for mining and interactive payments even when he had P2PKH available, or did he have some other reason for using different transaction types? I think only he knows.

In a situation where you don't need the shorter P2PKH addresses, such as mining, interactive payments, or paying to your own pubkey for change, using a P2PK may be the better option, although there is a security advantage to P2PKH if you don't reuse addresses and if ECDSA someday gets broken in a certain way that makes attacks possible but slow to execute.

```
Type   Output                Input             Total Bytes
       ScriptPubKey          ScriptSig

       push ....... 1        push  ... 1
       <key> ...... 33       <sig> ... ~72
P2PK   checksig ... 1
       --------------        -------------
       Total ...... 35       Total ... ~73     ~108

       dup ........ 1        push .... 1
       hash160 .... 1        <sig> ... ~72
       push ....... 1        push .... 1
P2PKH  <hash> ..... 20       <key> ... 33
       equal ...... 1
       checksig ... 1
       --------------        --------------
       Total ...... 25       Total ... ~107   ~132

```

The numbers above assume that you're using a [compressed public key](https://bitcoin.org/en/developer-guide#public-key-formats), which are widely used today but were not implemented until [Bitcoin Core 0.6.0](https://bitcoin.org/en/release/v0.6.0). If you want to consider the older "uncompressed" public keys, add 32 bytes to the `<key>` byte sizes. Also, we ignore all constant factors in creating an output or input and just consider the number of bytes in the script.

I'm not aware of any compatibility issues---plenty of miners and mining pools use their own software to pay to P2PKH addresses, as you can see from the coinbases in recent blocks.

> **Comments:**
> **username_3**: Is it possible, that this is information outdated? I had coffee last week with username_4, and he calculated `PREVOUT + SCRIPTSIG = 36 + (1 + 1 + 33 + 1 + (71 or 72)) = 143 or 144`  for the P2PKH input.  
> **username_4**: The numbers here 1) don't include the prevout and 2) assume an uncompressed pubkey.  
> **username_2**: @username_3 I updated the answer to use compressed pubkeys, to mention uncompressed pubkeys, and to mention what's not counted.  I believe all the calculations were (and are) correct; however, some of the historical information was wrong (as I've learned since first writing this answer) so I corrected that.  Also, I'm glad you and username_4 were able to have coffee together. :-)  

---

