Topic: What is the difference between public key and public key hash. (Read 395 times)

Thanks for mentioning his reply, I think I missed it out, I did not read pooya's reply, and thanks for the explanation you have made, the things are now crystal clear for me between encryption and hashing, I definitely get confused in them but from now on I will not.

Thanks a lot dear Pooya87, for your explanation, sorry, I did not saw that reply, I don't know how it missed, but if I would have saw that then I might have not made my 2nd reply here. Because your reply was enough but I am glad that I asked, because leo has made things more easy.

No. They are made by hashing the public key.

Pooya87 has explained the difference between hashing and encryption on the previous page: https://bitcointalksearch.org/topic/m.62907603

Encryption is a two way process, where anyone with the decryption key can decrypt the result and obtain the original message. Hashing is a one way process, which is not reversible, which outputs a message of a fixed size.

If you know an address, you cannot calculate the public key, because the address is hashed, not encrypted. It is a one way process which is not reversible.

Still, better to use real examples so OP can test the examples locally if they want to. For example, the valid public key based on your x coordinate is:

Take RIPEMD160(SHA256(public key)):

Add the network byte 0x00:

Take the double SHA256 hash of this:

Take the first four bytes of this string as a checksum (0x3F53E136), and append it to the public key hash:

Encode in to Base58 to get your address:

Really! I mean aren't they made by encrypting the public key?
This is just an example, to show the OP what it actually looks like.

When you want to talk about size of transactions it is better to consider both transactions, the one creating the output and the one spending it. In this case the sum total size of the two transactions is larger when using the scripts that contain the pubkey hash instead of the public key itself (ie. P2PKH vs P2PK for example) because there is an additional hash size (20 bytes) and additional OP codes (each one byte) in the scripts.

Interestingly, pubkeyhash came before compressed public keys.

While addresses and public key hashes are mentioned in Satoshi's initial v0.1 announcement email, it seems that Satoshi simply didn't know that public keys could be compressed in the way that we do now. The size difference between an uncompressed public key and an address is obviously much greater than the size difference between a compressed public key and an address.

An uncompressed public key is 130 characters. If you want to encode that with Base58Check, then your resulting string is 95 characters.
A compressed public key is 66 characters. If you encode that with Base58Check, then your resulting string is 51 characters.
A standard legacy address is 33/34 characters.

A reduction in size from 95 to 34 (61 characters) is much more meaningful than a reduction from 51 to 34 (17 characters). Would we even have P2PKH addresses at all had Satoshi known about compressed public keys?

Seems like nobody answered that. The significance of the public key hash is that it shortens the scriptPubKey, which in consequence shortens the transaction size. Compressed public keys are 33 bytes, whereas a RIPEMD-160 hash is 20.

---

Public key hashes provide no security whatsoever. Even if the attacker cannot work out the private key while the transaction is unconfirmed, the entire system is just so reliant on public keys that it'd be complete ignorance to even call it security. Signed messages, Taproot, lightning, billions of dollars worth of bitcoin with known public keys, SPV servers with master public keys stored etc.

I am following your conversation and without wanting to add something to what other users already said, I thought the following image could be helpful.

But still, public key hashes provide no real benefit. You are first assuming that a quantum computer capable of solving the ECDLP suddenly appears out of nowhere and we have no time to react. This is highly unlikely to happen, given we are all aware of quantum developments and discussions regarding quantum proof algorithms are already ongoing. What is far more likely is that we will transition to a quantum proof algorithm long before the first private key is attacked.

And if a computer which can break ECDLP does pop up out of nowhere, then as I've explained above the majority of coins are in addresses with revealed public keys. Having your bitcoin secured behind a hash is little consolation if the network collapses because 10 million bitcoin have been stolen.

If pubkey hashes actually provided any meaningful security, then we wouldn't be moving away from them with taproot addresses, which reveal the public key just from the address.

Yes and no. Yes, pubkey hashes are no long term solution, but they can still serve as stopgap as long as you avoid reusing addresses. That is to say, there will probably be a couple of years between the first quantum computer deriving a private key and the first quantum computer being fast enough to do the same while a transaction is still in transit.

No problem.

Here is an example of transaction I just pulled from a recent block spending coins from a standard P2PKH (pay to pubkey hash) output - https://mempool.space/tx/ec8d6d318f0a73423782074cc1e73f8675af47b4f7fe574745c6cb1d2f95480d. If you click on "Details" and then look at the "Previous output script", you'll see the following:

To spend such coins, your wallet will provide a signature for this address followed by the original unhashed public key. This set of instructions will first duplicate the public key (OP_DUP), then pass it through two hash functions (OP_HASH160). It will then verify that this hash value is equal to the hash value given above (OP_EQUALVERIFY). If it is, then it will check the signature you provided against the unhashed public key (OP_CHECKSIG). If the signature is valid, then the transaction can be broadcast and mined.

Here is an example of transaction spending coins from a P2PK (pay to pubkey) output - https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16. (This is actually the first bitcoin transaction from Satoshi to Hal Finney.) Again, if you click on "Details", you'll see the following:

To spend such coins, all you need to provide is a signature. The string in the locking script above is the public key, and so you do not need to provide the public key as you did with a P2PKH output. Just provide a signature and OP_CHECKSIG will check your signature against the public key which is already there.

P2PK outputs are very rarely used these days, but there remains several million bitcoin on dormant on such outputs from the early days of bitcoin. But yes, public keys and public key hashes are different things which need to be unlocked with different scripts.

Thanks, I didn't know that but since I am not technically strong yet this is one more information I can learn today.

Using pubkey hashes provides little realistic security when it comes to quantum computers. Public keys are meant to be public. That's the whole point. No wallet, software, or service treats and handles public keys securely as it does with private keys. There are dozens of reasons your public keys will already be exposed, from transactions, signing messages, light wallets syncing with third parties, address reuse, multi-sig, taproot, use in BIP32, use in descriptors, and so on. And even if you personally keep your public keys completely secure on an airgapped machine and only use addresses in a watch only wallet, probably the majority of bitcoin out there is in addresses with public keys which have been revealed one way or another.

Quantum resistance will come from forking to a quantum resistant algorithm and depreciating ECDLP altogether, not from using public key hashes.

Finally got someone who is taking Quantum computing serious, mostly people are not taking it serious for now. It may take 10 to 20 years (may be more or less no one is certain) for quantum computers to arrive but its good that we start preparing for it. There wont be any digital sector which wont be affected by the quantum computing.

I feel like you are confusing 3 different algorithms with each other.
1. Encryption
This is a reversible operation where you create a "ciphertext" from a message using a password. The one with the password and the ciphertext can decrypt it to get the message.
Combining encryption with public key cryptography will give us the hybrid systems such as ECIES where you can encrypt a message using the other party's public key so that they can decrypt it using their private key.

2. Hashing
This is an irreversible operation where you compute a fixed size digest from an arbitrary size message. In bitcoin (addresses) we use hash functions to shorten the public key (or the arbitrary size script in pay to script addresses) and consequently the size of the address that needs to be copied.
It's purpose is not to "hide" the public key since there is no security risk in revealing your public key in an asymmetric cryptography. If there were, the algorithm would have been obsolete.

3. Digital Signature Algorithm
To put simply in the asymmetric cryptography algorithms you use a DSA to prove you own the private key to the revealed public key. For example in Bitcoin you sign a transaction with your private key (using ECDSA or ECSDSA) to satisfy the conditions in the smart contracts containing any of the OP_CHECK(MULTI)SIG(VERIFY) operations, so that you can spend the coins you have.

Private keys sign transactions. Public keys verify transactions. Hashing a public key allows for keeping the public key secret until an outgoing transaction is made, which provides an additional layer of security, especially keeping the future possibility of quantum computing attacks in mind.

No, it isn't. It is a hashed version of the public key. Coins sent to a public key and coins sent to a public key hash have completely different unlocking scripts.

P2SH (pay to script hash) addresses are hashes of a script, not necessarily hashes of a public key.

Hashing is not the same as encryption. Pubkey hashes are not encrypted public keys.

This is not a valid public key.

Not exactly.

To create, for instance, the  legacy address, we add to public key hash ( [Ripemd160[sha256(pubkey)]] the network type as a prefix (0x00 - if mainnet) and concatenate the checksum (which is equal to first four bytes of  [sha256[sha256([Ripemd160[sha256(pubkey)]])  with the resulting string that should  undergo a  BASE58 conversion to get the target address.

Thus,  public key hash is used to create address but they are  not exactly the same.

The procedure in which it involves depends on type of address.


Public key hash, this concept is usually implies the digest of the  blending hash function Ripemd160[sha256(pubkey) that takes pubkey as a message.

Always the same questions...

Please read the next link: Chapter 4. Keys, Addresses, Wallets

Also you can found the full book on github and the pdf in some other pages.

I would like to add my version, which is that the public key is used to encrypt data, and the other party will use the private key to decrypt the encrypted data. Public key hashes are the encrypted form of the public key, which is smaller in size and is the compact one.

This means that to secure the private keys, we use public keys, and to secure the public keys, we use public key hashes.

Let's say you have a public key:
044f40875d8b57f9d80e12b54677893997c7573bf176711680356e0336a8c7b29fa26599a933e92 c3f8399587f38818991759b7a2778c74c86a17f25b8e9a272b

Public key hash: 18d2e54761a9465a1943399808d63097c591451c

Encryption method of creating a hash key is different and it should be, and the key must be kept save otherwise your public key will be exposed.

The public key hash is our the wallet address. Bitcoin address is a hashed version of our public key derived from private key.
There are different types of them one of them is P2PKH and P2SH read more here Bitcoin address types compared: P2PKH, P2SH, P2WPKH, and more

If you want a better explanation about this I suggest read this "Public Key Hash Explained".