Why don't P2PK scripts have their own address?

Question

If I understand addresses correctly, different types of addresses are used to map to a particular locking script (scriptPubKey).

So based on the leading character of an address, a wallet will decode the address, and then form the appropriate locking script around it.

For example:

P2PKH = 1address

13qWKACQWgQDwDRDoRtqUbN59bar6ousQf
OP_DUP OP_HASH160 1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c OP_EQUALVERIFY OP_CHECKSIG

P2SH = 3address

3MmRfLoNzap2Mt8PwHqhVtxHsmdRieuXfk
OP_HASH160 dc37feb38b5a4ad4bf09bc61eea4831f85c58103 OP_EQUAL

P2PK = n/a

n/a
031b0e8c2567c12536aa13357b79a073dc4444acb83c4ec7a0e2f99dd7457516c5 OP_CHECKSIG

Why is it that P2PK scripts have never been given their own address?

Why not give the public key in a P2PK a checksum, then base58 encode it with it's own leading character so that we can have an address for it?

Answer 1

One of the issues with encoding P2PK outputs as an address is that they can be very long. P2PK can have both compressed and uncompressed keys. Uncompressed keys are 65 bytes, which means that the resulting address would be very long. In fact, this length is probably why P2PKH exists in the first place: as a way to have short strings as addresses. So P2PK addresses could be very long and unwieldy, so not that useful.

But nowadays, everyone uses compressed pubkeys so length isn't much of an issue anymore.

Since Satoshi didn't give P2PK an address type, the reason that one has not been created since then is that no one cares to. P2PKH already does everything P2PK does, just a little bit longer. And with other improvements coming such as Taproot (which is A pay to pubkey scheme and has its own address type), there isn't a compelling reason to go through the effort of defining a standard and trying to get wallets to implement it.

Answer 2

I think there is a mix of transaction type (p2pk, p2sh, p2pkh...) and pubkeys or addresses. The addresses are generated from the hex pubkey (a cool playground here: http://gobittest.appspot.com/Address). The pubkeys are hashed, a network Byte added, some check summing and base58check encoded. This gives me the bitcoin address of a public key.

In a transaction I can use different methods to transfer funds. I had replied to your other post as well. So when the spending condition only requires you to present your public key and signature, then it is a p2pk transaction. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.

If the spending condition is set to present a public key hash, then it is a p2pkh tx, and you have the std Op_Dup, Op_Hash160,... structure.

When having a look onto the stack, it becomes clear, what happens. The spending tx puts its sig and pubkey on stack. Then the pubkey script goes onto stack. First command is OP_Dup, so pubkey is duplicated. Then OP_Hash160 follows, hashing the pubkey. This hash is then compared with the hash of the pubkey script (in your example „1f1cafe31d63e061a3f74b541f4ce7a4515b4d0c“), and hopefully these two match (as per the following OP_Equal). This proves, that you are the rightful person to spend the funds, cause you could proof, that you can hash your pubkey to the referenced pubkey hash. And hashing is a one way function... no one else could do this. In the last step, the signature in the transaction is verified, and with your now provided pubkey the transaction would be checked for a valid signature (OP_Checksig).

Hope I could shed some light in the confusion on addresses and „pay to pubkey“ or „pay to pubkey hash“ transactions :-)