<p>by the specification.</p>

<p>they are not "typically longer"</p>

<p>they are "always longer by 1 symbol"</p>

CC BY-SA 3.0
2016-02-27T14:11:14.810Z
2016-02-27T14:11:14.810Z
amaclin
<p>Because they are not <em>compressed private keys</em>. They are <em>private keys with a marker that indicates that their corresponding public should be compressed</em>. That extra marker takes an extra byte.</p>

CC BY-SA 3.0
2016-02-27T15:12:55.087Z
2016-02-27T15:12:55.087Z
Pieter Wuille
<p>From what I understood, compressed private keys are supposed to represent the same secret key, stored more efficiently thus taking up less space. I assume 'more efficiently' has to do with secp256k1 specifics that I'm not aware of, but I'll take that for granted.</p>

<p>However, when I compare a few compressed and uncompressed private keys:</p>

<pre><code># example private key
hex: 
85B7DFAB8D2C695C0EBF013AD50A758FDBC62775391B7CE33282634F7DB47480
uncompressed:
5JqBEaUuYJFA4dQsd62ys13RumxCGu97BRu3LzwaVduD8MQnFwc
compressed:
L1heAvnAu97V11iNSHDjyhBiwwQcmB8nH2thMGjtqPsSXKaZ9VwY

# another example private key
hex:
6190289CEB09ED41776AE27AE81F46C6540C56CF8F3900BCAADE96B4470F23D6
uncompressed:
5JZFhabXLayCMCehpyhdCPZ5LXwvgvu3gX4Png4xYzCWYCXJ3jx
compressed:
KzVMt7HNuSw36ARRCmGJmGYa9DbRyEtiqRfyabSUCBToNRwMrAog

# yet another example private key
hex:
763B1998BF7282A99CA21EB821EB9A204589FFA189E290EE64528854FDA91080
uncompressed:
5JiMdW1Czd3tTuy33wiC5wmrkhZxx2PNcC7NVZoFc7AixTVgmf5
compressed:
L1BY471uwL7k9nnL3zUovpkzbt4Vws7kNL37s5m9TxDvBjnadvMy

# etc
</code></pre>

<p>I notice that the <em>compressed</em> version (at least the WIF/base58 representation) of a key always seems to be <strong>longer</strong>. Why's that?</p>

<private-key><base58check><wallet-import-format>
Why are compressed private keys typically longer than their uncompressed counterpart?
RocketNuts
# Why are compressed private keys typically longer than their uncompressed counterpart?

(Asked by: username_0 on 2016-02-27)

From what I understood, compressed private keys are supposed to represent the same secret key, stored more efficiently thus taking up less space. I assume 'more efficiently' has to do with secp256k1 specifics that I'm not aware of, but I'll take that for granted.

However, when I compare a few compressed and uncompressed private keys:

```
# example private key
hex: 
85B7DFAB8D2C695C0EBF013AD50A758FDBC62775391B7CE33282634F7DB47480
uncompressed:
5JqBEaUuYJFA4dQsd62ys13RumxCGu97BRu3LzwaVduD8MQnFwc
compressed:
L1heAvnAu97V11iNSHDjyhBiwwQcmB8nH2thMGjtqPsSXKaZ9VwY

# another example private key
hex:
6190289CEB09ED41776AE27AE81F46C6540C56CF8F3900BCAADE96B4470F23D6
uncompressed:
5JZFhabXLayCMCehpyhdCPZ5LXwvgvu3gX4Png4xYzCWYCXJ3jx
compressed:
KzVMt7HNuSw36ARRCmGJmGYa9DbRyEtiqRfyabSUCBToNRwMrAog

# yet another example private key
hex:
763B1998BF7282A99CA21EB821EB9A204589FFA189E290EE64528854FDA91080
uncompressed:
5JiMdW1Czd3tTuy33wiC5wmrkhZxx2PNcC7NVZoFc7AixTVgmf5
compressed:
L1BY471uwL7k9nnL3zUovpkzbt4Vws7kNL37s5m9TxDvBjnadvMy

# etc

```

I notice that the *compressed* version (at least the WIF/base58 representation) of a key always seems to be **longer**. Why's that?

**Tags:** private-key, base58check, wallet-import-format


---

## 2 answers

### Answer by username_2 on 2016-02-27. Score: 6 | Accepted answer

Because they are not *compressed private keys*. They are *private keys with a marker that indicates that their corresponding public should be compressed*. That extra marker takes an extra byte.


---

### Answer by username_1 on 2016-02-27. Score: 0

by the specification.

they are not "typically longer"

they are "always longer by 1 symbol"


---

