This script pattern is used to “send” someone bitcoins. It’s the most common script used for locking an output to someone’s public key.
It is similar to P2PK, but the lock contains the hash of a public key instead (and not the public key itself).
How does P2PKH work?
The P2PKH script pattern contains a
hashed public key surrounded by these opcodes:
|hex | opcodes||inline | stack|
To solve this script, the owner of the hashed public key above needs to provide the original
public key, along with a valid
signature for it:
|hex | opcodes||inline | stack|
In short, when this script runs:
- The original
DUPlicated and then
- This hashed value is compared with the
hashed public keyin the scriptPubKey to make sure it is
- If it matches, the script continues and the
public key(just like a P2PK script).
Where can you find P2PKH scripts?
P2PKH is the default script used by wallets when you want to “send” someone bitcoins, so you can find it in most blocks in the blockchain.
Here are some interesting transactions that use P2PKH:
6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516- First P2PKH Transaction (16th January 2009)
a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d- Pizza Transaction (10,000 BTC)
Why do we have P2PKH as well as P2PK?
If P2PK does a good job of locking up bitcoins to a public key, why do we have the more complex P2PKH script?
Only Satoshi knows why we started using P2PKH, but the reason probably goes something like this…
Satoshi wanted a easier way for people to be able to share their public keys with each other. Satoshi knew that you could make public keys:
However, the result was still pretty big:
Therefore, a solution for getting an even shorter result is to hash the public key first:
So there we have a much shorter version of our public key (we call it an
address) that we can easily share with other people. Any wallet software can then take this address and decode it from base58 to get the
public key hash, which can then be set inside a locking script.
Now, the only thing we have to do to make this work is to change the locking mechanism so that we lock an output to the hash of a public key. Then, we provide the original public key we come to unlock it, and the hash of that will be checked before carrying on with the signature check as normal:
It’s a bit more complex from a programming perspective, but it does allow for the use of shorter and more convenient addresses for sending and receiving bitcoins.
I think Satoshi ultimately had usability in mind for Bitcoin, and that’s why we have P2PKH.
Would we still use P2PKH if Satoshi knew about compressed public keys?
Maybe, maybe not. Good question.
If you base58 encoded a compressed public key you would get an address that is 51 characters long (as opposed to the 34 characters you get by hashing it beforehand), so there may not have been as much as an incentive to hashing before creating an address:
Nonetheless, P2PKH had become the standard for sending and receiving bitcoins by this point, so that’s why we have stuck with it.
Still, it would have been simpler to have used P2PK from the start.