20

Why do you hash the public key twice? Are there security benefits to abstracting away from the public key? Is it because the address can represent multiple things? I'm missing something.

Could you theoretically send bitcoins directly to the public key?

ihtkwot
  • 331
  • 2
  • 6
  • :/ this is not a well formed question. what are you talking about? the fact that the key is hashed? – smatthewenglish Oct 24 '16 at 18:50
  • 2
    The fact that you hash the key twice, with SHA256 and RIPEMD160. Why go through the process? I'm working through Mastering Bitcoin, and he didn't explain very well why we need addresses. – ihtkwot Oct 24 '16 at 18:56
  • it's it becasue it's some kind of special encoding that removes l and 1, something like that, to make then easier to read – smatthewenglish Oct 24 '16 at 19:01
  • It's just to make them easier to read? So, if that's the case, could you theoretically send bitcoin directly to the public key instead of the address? – ihtkwot Oct 24 '16 at 19:02
  • maybe. how would you get the private key in isolation? – smatthewenglish Oct 24 '16 at 19:33
  • @s.matthew.english: Base58Check is just an encoding to present large numbers in a more readable fashion. It can be applied to Public Keys just as it can be to addresses. – Murch Oct 24 '16 at 19:55
  • The double hash is to protect against length-extension attacks. There's no reason to think you'd be vulnerable to such attacks, but it's a cheap way to ensure you don't even have to think about it. There is a slight security advantage in that the public key can be kept secret for longer, if desired. As stated below, Satoshi use a hash to keep the address as short as possible. – David Schwartz Oct 24 '16 at 23:58

2 Answers2

20

Yes, you could send bitcoins directly to the public key: in fact, both Pay-to-PubKey (P2PK) and Pay-to-PubKey-Hash (P2PKH) were introduced in the first Bitcoin release. IIRC, P2PK is still used for Coinbase transactions sometimes, today.

P2PK transactions are slightly bigger for outputs but significantly smaller for inputs.

One advantage of P2PKH is that addresses are shorter than public keys. This allows addresses to be represented with 34 characters in Base58check.
If there were a standard to present public keys in Base58check, they'd probably have 51 characters. Arguably, it is easier to type a character jumble that is only 34 characters than one that is 51 characters.

But really, addresses get used because there is a standard for them and there is none for public keys. Why that is so, I don't know.

All credit to Pieter, who has provided the knowledge to amend my errors. ;)

Also see this related question: Why does the default miner implementation use pay-to-pubkey?

Murch
  • 75,206
  • 34
  • 186
  • 622
  • WIF is a format for private keys, not addresses. I also have never seen a standard for P2PK addresses. – Pieter Wuille Oct 24 '16 at 21:13
  • @PieterWuille: Corrected WIF to Base58. I don't get your comment about "P2PK addresses"? – Murch Oct 24 '16 at 22:02
  • You say "public keys (51 characters in Base58), but AFAIK no standard exists to encode public keys as base58. – Pieter Wuille Oct 24 '16 at 22:15
  • @PieterWuille: Wouldn't it be the same length as a private key because it's also a 256 bit number? – Murch Oct 24 '16 at 22:17
  • Well, yes, it would be, but that seems an irrelevant hypothetical. The biggest reason why people don't make P2PK outputs is that there is no address standard for it. You can argue why such a standard does not exist (as your answer points out, size is one reason), but you're skipping a step. – Pieter Wuille Oct 24 '16 at 22:20
  • @PieterWuille: I guess I have too much half-knowledge. :p – Murch Oct 24 '16 at 22:20
  • @PieterWuille Are there any other reasons? – Murch Oct 24 '16 at 22:28
  • 3
  • Compressed pubkeys weren't known when P2PKH address types were defined (so it'd be 95 base58 characters). 2) Higher cost to the sender. 3) Longer opportunity for hypothetical ECDLP attackers (which need to full pubkey).
  • – Pieter Wuille Oct 24 '16 at 23:12
  • 1
    Without checksums and prefixes a compressed pubkey is 33bytes, 45 bytes base58 encoded, vs 87 bytes uncompressed. The ECDLP attack prevention is the best reason. Without the pubkey, you basically have nothing to attack. – Erik Aronesty Jun 05 '18 at 21:10