user238: The standard Bitcoin client in version 0.6 apparently introduces compressed keys.
What are they? Are there any drawbacks to using them? Any incompatibilities with older software? Reductions in cryptographic strength?

user30396: a good explanation is available in How can I test if a bitcoin address is compressed or not? 

More specifically, a public key in Bitcoin is a pair integers (x,y).
  For uncompressed public keys, these integers are encoded as 256-bit
  unsigned big-endian ints, concatenated together, and then prepended
  with a single 0x04 byte. The result is 65 bytes long.
For compressed public keys, only the x coordinate is encoded (like
  above, as 256-bit unsigned big-endian int). It turns out that the y
  coordinate can only be one of two values, one even and one odd.
  Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte
  is prepended depending on y's value (0x02 for even, 0x03 for odd). The
  result is 33 bytes long.


user11538: It may help to break the fields apart.

04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

03 [could be 02]
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
[discarded value can be computed from above value]

There is more detail omitted above. The 03 can be 02 because the
discarded value has to be derived from the preserved value and
one extra bit of info is needed. That is because there are two
roots [plus and minus] when taking a square root.

user479: Format (private keys):

uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of
previous 33 bytes], base58 encoded
compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash()
previous 34 bytes], base58 encoded

case 1:

secret (hex):
1111111111111111111111111111111111111111111111111111111111111111
uncompressed:

secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh


pubkey (hex):
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1


address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a

compressed:

secret (base58): KwntMbt59tTsj8xqpqYqRRWufyjGunvhSyeMo3NTYpFYzZbXJ5Hp


pubkey (hex):
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa


address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9


Obtained from the Bitcoin developer mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development


user85: A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.
If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the x and y coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve secp256k1, but the concept is the same.)

238: <p>The standard Bitcoin client in version 0.6 apparently introduces compressed keys.</p>

<p>What are they? Are there any drawbacks to using them? Any incompatibilities with older software? Reductions in cryptographic strength?</p>
 30396: <p>a good explanation is available in <a href="https://bitcoin.stackexchange.com/questions/37373/how-can-i-test-if-a-bitcoin-address-is-compressed-or-not">How can I test if a bitcoin address is compressed or not?</a> </p>

<blockquote>
  <p>More specifically, a public key in Bitcoin is a pair integers (x,y).
  For uncompressed public keys, these integers are encoded as 256-bit
  unsigned big-endian ints, concatenated together, and then prepended
  with a single 0x04 byte. The result is 65 bytes long.</p>
  
  <p>For compressed public keys, only the x coordinate is encoded (like
  above, as 256-bit unsigned big-endian int). It turns out that the y
  coordinate can only be one of two values, one even and one odd.
  Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte
  is prepended depending on y's value (0x02 for even, 0x03 for odd). The
  result is 33 bytes long.</p>
</blockquote>
 11538: <p>It may help to break the fields apart.</p>

<pre>
04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

03 [could be 02]
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
[discarded value can be computed from above value]
</pre>

<p>There is more detail omitted above. The 03 can be 02 because the
discarded value has to be derived from the preserved value and
one extra bit of info is needed. That is because there are two
roots [plus and minus] when taking a square root.</p>
 479: <p>Format (private keys):</p>

<ul>
<li>uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of
previous 33 bytes], base58 encoded</li>
<li>compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash()
previous 34 bytes], base58 encoded</li>
</ul>

<p>case 1:</p>

<ul>
<li>secret (hex):
1111111111111111111111111111111111111111111111111111111111111111</li>
<li>uncompressed:</li>
<li><ul>
<li>secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh</li>
</ul></li>
<li><ul>
<li>pubkey (hex):
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1</li>
</ul></li>
<li><ul>
<li>address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a</li>
</ul></li>
<li>compressed:</li>
<li><ul>
<li>secret (base58): KwntMbt59tTsj8xqpqYqRRWufyjGunvhSyeMo3NTYpFYzZbXJ5Hp</li>
</ul></li>
<li><ul>
<li>pubkey (hex):
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa</li>
</ul></li>
<li><ul>
<li>address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9</li>
</ul></li>
</ul>

<p>Obtained from the Bitcoin developer mailing list:</p>

<ul>
<li><a href="http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&amp;forum_name=bitcoin-development" rel="noreferrer">http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&amp;forum_name=bitcoin-development</a></li>
</ul>
 85: <p>A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.</p>

<p>If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the <em>x</em> and <em>y</em> coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve <a href="https://en.bitcoin.it/wiki/Secp256k1">secp256k1</a>, but the concept is the same.)</p>
