16

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?

Improve this question

3 Answers 3

Reset to default
22

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 changes 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.

Improve this answer
2
  • 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
    Commented Mar 11, 2018 at 17:58
  • 1
    That's my guess, yes. A base58 uncompressed pubkey address would be 95 characters.
    – Pieter Wuille
    Commented Mar 11, 2018 at 18:05
6

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)

Improve this answer
6
  • 1
    You deserve more upvotes because of the D-Wave part
    – Osias Jota
    Commented Mar 11, 2018 at 13:46
  • 2
    @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
    Commented Mar 12, 2018 at 4:22
  • 1
    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
    Commented Mar 12, 2018 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
    Commented Mar 12, 2018 at 12:33
  • 1
    @inersha If it's going to be spent, as you said, P2PK is more compact overall.
    – MCCCS
    Commented Mar 12, 2018 at 13:39
3

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...

Improve this answer
2
  • 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
    Commented Mar 11, 2018 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
    Commented Mar 11, 2018 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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