If elliptic curve cryptography is secure enough to be able to give away a public key without fear of anyone being able to calculate our private key from it, what's the reason for hashing our public key for use in P2PKH?

In other words, what's the benefit of a more complex system for locking and unlocking bitcoins, if a simple P2PK transaction is secure enough?

I'm not against extra security, but why is it not considered to be redundant?

up vote 10 down vote accepted

The original reason why addresses were a public key hashes is something you'll need to ask Satoshi. My guess however is that it was just shorter and more convenient (note that compressed public keys weren't known at the time).

When compressed public keys were discovered it was simply easier to stick to the existing address scheme (it didn't require any changed at all; wallet and node software happened to already support compressed public keys). Introducing a new address scheme that was both more expensive for the sender (34 bytes of output script rather than 25) would have been nearly impossible to convince the ecosystem of - knowing that deployment of P2SH even took several years.

One often repeated argument in favor is quantum resistance. I believe this is besides the point. We have no idea what the characteristics of a hypothetical machine relying on yet to be invented technology will be. Given the degree of key reuse on the network (so there are addresses with known public keys), the existence of a system that can break ECDSA is likely a death blow to Bitcoin. A real solution to that is to prepare and have real quantum-resistant cryptography in place before it's too late. Relying on a weird hope that those hypothetical machines are somehow too slow to steal from unconfirmed transactions before they're mined is a red herring.

  • A great insight, thank you Pieter. – inersha Mar 11 at 17:26
  • So even though a P2PKH will ultimately take up more space on the blockchain (pubkeyhash | pubkey, signature) than a P2PK (pubkey | signature), the motive for hashing the uncompressed key was to make it more convenient to pass around? – inersha Mar 11 at 17:58
  • 1
    That's my guess, yes. A base58 uncompressed pubkey address would be 95 characters. – Pieter Wuille Mar 11 at 18:05

The public key is first SHA256 hashed and then RipeMD160 hashed. A Bitcoin address is actually an encoded hash of the public key.

A public key is 65 bytes long (0x04 + 64 bytes public key) or 33 bytes when compressed (0x02 | 0x03 + 32 bytes public key).

However, why not RipeMD160 it and make it shorter? It'd become 20 bytes. Of course, it'd be great if it were shorter, an address shouldn't be long.

Why RipeMD160? RipeMD collision was reported in 2004 (ref), so maybe NSA can also break Ripemd160? So, Satoshi decided to SHA256 hash it first and then RipeMD160 it, which means it'd be much harder for an attacker to find a preimage to steal Bitcoins.

TL;DR shorter addresses, as well as protection for far future's quantum computers. (Even D-Wave doesn't own a quantum computer now. It's a quantum annealer. ref)

  • 1
    You deserve more upvotes because of the D-Wave part – Osias Jota Mar 11 at 13:46
  • Thanks. So if I understand your reply correctly... Even though P2PKH scripts take up more space in the blockchain, it's worth it for future-proofing against quantum computers? – inersha Mar 11 at 14:58
  • @inersha Yes, one day people will be encouraged to migrate their money from old addresses to quantum-proof addresses, on that day, if you can't spend your funds (locktime, etc...) you'll have hard times about the uncertainty (Will quantum computers steal my money? Will the locktime end before quantum computers crack my addresses?) If you'll have had moved your coins to an address who've never spent (in other words, public key is not revealed), you can be sure that your coins are safe (at least for 10-20 years after then). But that will happen at least 10years later,so it'snotneededcurrently – MCCCS Mar 12 at 4:22
  • And no, P2PKH saves blockchain's space. When sending to a P2PKH address, you're sending to a 20 byte hash (+1 byte OP_HASH160) instead of 33 or 65 bytes. – MCCCS Mar 12 at 4:27
  • 1
    @MCCCS But with P2PKH, don't you have to provide the (publickey + signature) when you come to spend it anyway? Whereas with P2PK you only have to provide the (signature) when you spend, so P2PK saves space overall? – inersha Mar 12 at 12:33

what's the reason for hashing our public key for use in P2PKH?

There is no link to ECDSA, besides that a priv key generates a pub key. But in the transaction, you would see the signature and the pubkey. So here we are talking more privacy (not ECDSA security). If a tx appears with a "pay to public key", then the tx spending script looks like this:

ScriptPubKey= <Public Key> OP_CHECKSIG
ScriptSig= <Signature>

whereas P2PKH uses this:

ScriptPubKey= OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
ScriptSig= <Signature><Public Key>

In the first example you can see the used public key when the transaction is generated (in the ScriptPubKey field). Miners would use such type of tx alot. In the P2PKH tx you see the pubkey only when it is spent.

Also note the difference on the spending condition, adding a layer of security. The stack executes the script of the ScriptPubKey, by copying (OP_DUP) the last item on the stack (<Public Key>). This public key is then hashed (OP_HASH160), and checked (OP_EQUAL). This means, when you want to spend this transaction, you have to show, that you can convert your public key (in the ScriptSig) to the same hash, as the sender put as reference in the tx (the pubkey hash). As hashes are a one way function, this is not reversible, and you cannot "steal" transactions. Imagine ECDSA was somehow broken, then hashing is not yet broken... You might be able to sign a tx, but you would still have to provide the correct hash. That is as per today's knowledge impossible. Though with broken ECDSA all other weird things might happen...

  • Thanks. So to summarize, do we primarily use P2PKH so that there's no link to ECDSA, because ECDSA security is not reliable enough? – inersha Mar 11 at 15:00
  • No, ECDSA is only used for key handling, to generate priv and public keys. Primary use case for P2PKH? See Pieter's response :-) – pebwindkraft Mar 11 at 20:59

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.