<p>Early renditions of the Bitcoin client did use raw public keys in this way for pay-to-IP-address transaction orders, it's still valid to spent an output to <code>&lt;raw pubkey&gt; OP_CHECKSIG</code>, though miners might not be willing to include it in a block. </p>

<p>Before an output owned by a fresh address is spent, the hidden public key points are unknown to anybody but the creator. If the situation arises that ECDSA is weakened there is only minimal exposure between signing a transaction and having it included in a block. To transition from a weakened ECDSA a new signature algorithm would be soft-forked into the consensus and outputs quickly shuffled over to using it instead. This bit of protection is effectively gained for free so it would be silly not to use it, though some wallets choose to re-use addresses multiple times which destroys the protection offered by this system.</p>

<p>As pointed out addresses are also appreciably shorter at 20 bytes rather than 33 or 64 bytes, which makes a difference if you have the need to manually transcribe one.</p>

CC BY-SA 3.0
2015-08-18T04:21:18.810Z
Thankyou for the answer! This protection is not free as it disables certain features which may lead to further innovations.
Kang
CC BY-SA 3.0
2015-08-18T04:59:39.523Z
It's free in the sense that all wallets do the hashing today, just some of them reuse addresses which removes the protection gained.
Claris
CC BY-SA 3.0
2015-08-18T05:21:55.567Z
Yes I understood that, but I meant restricting other use cases, for eg, if I knew someone's public key instead of just their compressed address, I could have written them a secret message on the blockchain.
Kang
CC BY-SA 3.0
2015-08-18T05:25:30.560Z
The block chain isn't designed for storing messages, it's for financial transactions. Messages are best sent along the channel you know the address from, like in BIP70.
Claris
CC BY-SA 3.0
2015-08-18T05:58:47.130Z
I gave an example, of how the additional protection is not free as it compromises certain possible uses. I did not mean to advocate that blockchain is a store of data.
Kang
CC BY-SA 3.0
2015-08-18T06:05:18.547Z
Right, I see what you're getting at.
Claris
CC BY-SA 3.0
2015-08-20T15:27:01.473Z
It's been harder to crack an address than a public key since day one. To generate a private key for an arbitrary address using is approximately 2^160 time complexity, whereas cracking a public key is only 2^128 time complexity. If it became possible to crack secp256k1 keys in a day, your bitcoins would still be safe provided you avoided address reuse. Also, the addresses are less vulnerable to quantum attacks.
ryanc
CC BY-SA 3.0
2015-08-18T03:01:28.833Z
2015-08-18T03:01:28.833Z
Claris
<p>What is the use of hashing the public key to obtain the bitcoin address (except to compress it) rather than using the public key directly?</p>

<p>Why not deal with public keys directly?</p>

<address><public-key>
What is the use of hashing the public key to obtain the bitcoin address?
Kang
# What is the use of hashing the public key to obtain the bitcoin address?

(Asked by: username_0 on 2015-08-18)

What is the use of hashing the public key to obtain the bitcoin address (except to compress it) rather than using the public key directly?

Why not deal with public keys directly?

**Tags:** address, public-key


---

## 1 answers

### Answer by username_1 on 2015-08-18. Score: 4 | Accepted answer

Early renditions of the Bitcoin client did use raw public keys in this way for pay-to-IP-address transaction orders, it's still valid to spent an output to `<raw pubkey> OP_CHECKSIG`, though miners might not be willing to include it in a block.

Before an output owned by a fresh address is spent, the hidden public key points are unknown to anybody but the creator. If the situation arises that ECDSA is weakened there is only minimal exposure between signing a transaction and having it included in a block. To transition from a weakened ECDSA a new signature algorithm would be soft-forked into the consensus and outputs quickly shuffled over to using it instead. This bit of protection is effectively gained for free so it would be silly not to use it, though some wallets choose to re-use addresses multiple times which destroys the protection offered by this system.

As pointed out addresses are also appreciably shorter at 20 bytes rather than 33 or 64 bytes, which makes a difference if you have the need to manually transcribe one.

> **Comments:**
> **username_0**: Thankyou for the answer! This protection is not free as it disables certain features which may lead to further innovations.  
> **username_1**: It's free in the sense that all wallets do the hashing today, just some of them reuse addresses which removes the protection gained.  
> **username_0**: Yes I understood that, but I meant restricting other use cases, for eg, if I knew someone's public key instead of just their compressed address, I could have written them a secret message on the blockchain.  
> **username_1**: The block chain isn't designed for storing messages, it's for financial transactions. Messages are best sent along the channel you know the address from, like in BIP70.  
> **username_0**: I gave an example, of how the additional protection is not free as it compromises certain possible uses. I did not mean to advocate that blockchain is a store of data.  
> **username_1**: Right, I see what you're getting at.  
> **username_2**: It's been harder to crack an address than a public key since day one. To generate a private key for an arbitrary address using is approximately 2^160 time complexity, whereas cracking a public key is only 2^128 time complexity. If it became possible to crack secp256k1 keys in a day, your bitcoins would still be safe provided you avoided address reuse. Also, the addresses are less vulnerable to quantum attacks.  

---

