15

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?

|improve this question
  • :/ 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
  • 1
    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
17

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?

|improve this answer
  • 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
  • 3
    1) 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 5 '18 at 21:10
13

As @Murch correctly pointed out it is indeed possible to send bitcoin to either a public key or to the hash of a public key. The original motivation for using hashes of public keys was to shorten the size of the address. Public keys in their uncompressed form are 64 bytes long whereas RIPE-MD outputs 20 bytes (+5 bytes of checksum and version).

Interestingly Satoshi did not know that public keys could be compressed to 32 bytes +1 bit (Why does Bitcoin support both compressed and uncompressed keys/addresses?) and thus chose hashes as a way to get compressed addresses. The security implications are interesting:

Unlike public keys, hash functions like SHA-256 and RIPE-MD are believed to be quantum resistant. A quantum attacker could thus efficiently retrieve the private key for any Bitcoin public key but not for a P2PKH address. However, whenever a transaction spends from a P2PKH address it reveals the public key as part of the script.

On the other hand the total number of possible address is 2^160 whereas the total number of public keys is roughly 2^256. Theoretically this means that addresses are less secure than public keys against a brute force attack. Obviously, a brute force attack is completely infeasible for either type of address.

|improve this answer
  • @benehsv your response is useful but the last point your make appears to me to be false however. You say PS2PK is harder to attack than PS2PKH. I think it is the opposite. With PS2PK the length benchmark is indeed 2^256. But with BTC addresses you don't just need to crack the BTC address back into a public key (2^256), that serves no purposes unless and until you then crack the public key back into its private key input for the EC curve (2^256). So actually the length benchmark is 2^(256+160)! Hence p2pkh is way more secure and complex to crack – Rodrigue Afota Apr 12 '18 at 13:43
  • 1
    @RodrigueAfota I am not sure that I agree. Say there is an address addr=H(g^(x)). The attackers goal is to find an x’ such that H(g^x’)=H(g^(x)). This x’ can be used to create a signature to spend the coins from addr This doesn’t meant that x=x’. If the RIPMD+SHA256 indeed have 160 bit security then the best attack runs in time roughly 2^160. If there are attacks on RIPMD the the best attack would be reduced (e.g. a quantum computer can do this in time 2^80). However I forgot to mention that the best classical algorithm for solving the discrete log problem already runs in time 2^128. – Benedikt Bünz Apr 18 '18 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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