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