P2PK vs P2PKH, is this right? I thought it would be alternative B that would have the transaction size saving property, since the pubkey is larger than the hash of the pubkey. #P2PK #P2PKH #thought #alternative #transaction #size #saving #property #pubkey #larger #hash #pubkey


P2PK vs P2PKH, is this correct? I considered it would be alternate B that would have the transaction dimensions preserving assets, because the pubkey is much larger than the hash of the pubkey.

View Resource

Share this post

Comments (3)

  • only_merit Reply

    There are two aspects of this. One is how big is the UTXO that you create when you pay to it and this boils down to the size of scriptPubKey. But then it’s also interesting what needs to be done for the receiver to spend it and this boils down to the size of scriptSig.

    In case of P2PK the scriptPubKey looks as follows:

    “`
    <PK> OP_CHECKSIG
    “`

    here `<PK>` is push instruction with argument of public key. P2PK can have both compressed and uncompressed keys. Compressed is shorter, 33 bytes, uncompressed 65 bytes. So one would use compressed. PUSH and CHECKSIG instructions are 1 byte each. So this would give you scriptPubKey which is 1 + 33 + 1 = 35 bytes.

    To spend that you’d need to produce a scriptSig. In this case it would be simply
    “`
    <SIG>
    “`

    i.e. PUSH instruction with an argument of the signature itself and how big is a signature is a bit complex (https://www.advancingbitcoin.com/blog/evolution-of-the-signature-size-in-bitcoin/) but let’s say it’s 71 bytes + 1 byte push = 72 bytes.

    So we would have:
    – sender creates a transaction with UTXO with 35 bytes scriptPubKey
    – receiver spends by providing scriptSig with 72 bytes

    With P2PKH situation is different:

    scriptPubKey is in form
    “`
    OP_DUP OP_HASH160 <PKHASH> OP_EQUAL OP_CHECKSIG
    “`
    each opcode is 1, PKHASH is push + 160 bits = 1 + 20 bytes = 21, total 25 bytes

    and scriptSig is in form
    “`
    <SIG> <PK>
    “`
    i.e. 72 + 34 = 106 bytes

    So from the sender’s point of view P2PKH is 25 bytes, which is less than P2PK with 32 bytes.

    From receiver’s point of view P2PK is 72 bytes, which is less than P2PKH with 106 bytes.

    Overall (system):
    – before UTXO is spent (how much UTXO set space) we have P2PK with 35 bytes vs. P2PKH with 25 bytes
    – after UTXO is spent (how much blockspace) we have P2PK with 35 + 72 = 107 bytes vs P2PKH with 25 + 106 = 131 bytes.

    November 24, 2022 at 3:37 am
  • pwuille Reply

    P2PKH has smaller outputs (created and paid for by the sender) than P2PK, but bigger inputs (which are created and paid for by the receiver when they spend the coins), because for P2PKH the full public key still has to be revealed at spending time.

    Payers have an incentive to prefer the smaller outputs, so the answer for those would be B, but they don’t actually have much influence over that, as the address/script type is chosen by the receiver.

    Receivers have an incentive to prefer the smaller inputs, so for those the answer is actually A.

    For nodes it’s a bit more complicated, as there are two relevant resources:

    * Bytes that end up on the blockchain. All of those bytes need to be transferred, processed, and to some extent, stored and made available. P2PKH, considering the sum of inputs and outputs, takes more bytes in total than P2PK. However, given the limit on block size (weight), the total is already bounded, and it doesn’t actually matter what people choose to use.
    * Bytes that end up in the UTXO set, which is the database of all unspent outputs. They need to be remembered from the time the output is created until it is spent. Only the output size matters for this, as inputs don’t go in there – they just need to be available at spending time. So from that perspective, the answer is B.

    November 24, 2022 at 3:37 am
  • meme_throwaway Reply

    What book is this?

    November 24, 2022 at 3:37 am

Leave a Reply


%d bloggers like this: