0

Call it a pay-to-public-key-script-hash (P2PKSH), like so:

  • Locking script:
    OP_HASH160 OP_DATA_20 redeem_script OP_EQUAL
  • Redeem script:
    OP_DATA_20 pubkey OP_CHECKSIG
  • Unlocking script:
    <push signature> <push redeem_script>.

Either way, wallets would have to process a list of keys and compute a 20-byte hash and address corresponding to each key, but address generation would be slightly different. Total size of prevout + input would be the same in either case:

  • P2PKH address (25 bytes):
    0x76a914 || hash160(pubkey) || 0x88ac
  • P2PKSH address (23 bytes):
    0xa914 || hash160(0x21 || pubkey || 0xac) || 0x87

Spending input script would also be slightly different:

  • P2PKH spend (66 + 34 bytes):
    <push signature> <push pubkey>
  • P2PKSH spend (66 + 36 bytes):
    <push signature> <push (0x21 || pubkey || 0xac)>

Note: || indicates byte concatenation.

Both would require support by applications such as wallets, and both would have the same transaction (input+output) size. The P2PKSH option has some advantage in that it would make the address relatively smaller and in that it would make all 20-byte outputs indistinguishable from each other.

It wouldn't make sense to start using this kind of address now, but there was a window of opportunity in the period 2012-2016 so I wondered. If Bitcoin had shipped with P2SH right from the start, would we have only 1 address type?

Improve this question

1 Answer 1

Reset to default
1

P2PKH had been around since the inception of Bitcoin and was therefore the dominant address type. When P2SH was introduced, it required wallet developers to implement both the parsing of P2SH addresses and the method of spending them. There's no benefit to using P2SH-P2PK, so it doesn't make sense for developers to implement it and users to use it.

This is in contrast to Segwit v0 and Taproot, both of which introduce new single key address types, but have benefits for using them. We've also observed that switching to new address types can be difficult and is a long and slow process. Given that P2SH-P2PK would have a similar issues with getting more usage, and that there is no benefit to using it, it's clear why P2SH-P2PK never caught on.

Improve this answer
3
  • Wasn't it all still small enough in 2012 so that it would've been possible to transition, with the argument of preseving privacy and having all types of outputs hide behind the hash? Was it ever discussed back before the idea of SegWit existed?
    – bca-0353f40e
    Commented Oct 31, 2022 at 15:55
  • 2
    I do remember reading about the idea of P2SH-P2PK, but it was several years after 2012; possibly even after segwit, so it's possible just nobody realized the possibility, or they didn't care about publishing the idea. Privacy isn't much of a benefit, as the redeemscript gets revealing on spending anyway (something that didn't change until P2TR). And despite the fact that scriptSig+scriptPubKey size for P2SH-P2PK is equal to that of P2PKH, it actually isn't financially advantageous for the receiver, as all they're doing is making it cheaper to send to them.
    – Pieter Wuille
    Commented Oct 31, 2022 at 18:05
  • That's right, it'd make spending costlier which would make a difference if you had lots of UTXOs you wanted to merge. Also yeah, privacy benefit is only for outputs at rest. Oh wow I looked up the string "P2SH-P2PK" and found that Armory actually supported those kinds of outputs! but that release was around the same time when SegWit was already a thing.
    – bca-0353f40e
    Commented Oct 31, 2022 at 20:02

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