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.

  • 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 Nov 20 '14 at 17:40
  • 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 Nov 20 '14 at 18:00
  • It's not possible to construct a P2PK from just a bitcoin address - therefore P2PKH must have existed at the beginning. – Nick ODell Nov 20 '14 at 18:01
  • I'm not saying it couldn't have been done, just that no one used P2PKH until later. – morsecoder Nov 20 '14 at 18:03
  • @NickODell recall that originally Bitcoin used 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 Nov 20 '14 at 18:07

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; 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, which are widely used today but were not implemented until Bitcoin Core 0.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.

  • 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 Aug 25 '16 at 23:29
  • 1
    The numbers here 1) don't include the prevout and 2) assume an uncompressed pubkey. – Pieter Wuille Aug 26 '16 at 20:51
  • 4
    @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 Aug 27 '16 at 12:50

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.