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)>
|| 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?