<blockquote>
<p>Have uncompressed keys always used the 04 prefix, even before compressed keys (which use 02, 03) were used?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>Did bitcoin undergo an update to add these prefixes to the different key types?</p>
</blockquote>
<p>There was no update to add prefixes.</p>
<p>Bitcoin wallet software did however undergo an update to make use of these compressed keys. There was no change to the consensus rules/implementation needed, because at the time OpenSSL was used for signature validation, and accepted both compressed and uncompressed public keys. In fact, there is a third type that was (and still is!) supported, <em>hybrid</em> keys, which use prefix <code>06</code> or <code>07</code> (depending on even/odd Y coordinate), followed by 32-byte X, <em>and</em> 32-byte Y coordinate. I do not understand the motivation for having such a type, but it is part of the implemented specification.</p>
<blockquote>
<p>If so, since these prefixes are included in the hash used to produce addresses, did addresses using uncompressed keys &quot;change&quot; when compressed keys were introduced?</p>
</blockquote>
<p>If these prefixes were indeed not present at first then introducing them would have been a hard fork. Thankfully, no change was necessary.</p>
<p>Of course, wallets transitioning from uncompressed to compressed pubkeys did need to change addresses. But ony the receiver cares about the distinction, as the sender only sees the 160-bit public key hash. At spend time, the receiver needs to reveal the full public key, whose hash needs to match the public key hash sent to.</p>
<p>If you have an extremely old Bitcoin Core wallet.dat file that has never been updated, and load it into a very modern Bitcoin Core 27.0 software, it will still produce P2PKH addresses using the uncompressed public key, so that one can still go back to old versions. This will not keep working however, as legacy wallet support is scheduled to be removed from Bitcoin Core. Such old files will still be usable, but will need to be converted to a modern format first.</p>
<p>Also note that since the introduction of compressed public keys, there have been actual new address types (<em>with</em> corresponding consensus changes): P2SH, segwit, and taproot.</p>

CC BY-SA 4.0
2024-06-03T23:23:48.283Z
2024-06-04T10:48:46.900Z
2024-06-04T10:48:46.900Z
Pieter Wuille
<p>Have uncompressed keys always used the <code>04</code> prefix, even before compressed keys (which use <code>02</code>, <code>03</code>) were used? Did bitcoin undergo an update to add these prefixes to the different key types? If so, since these prefixes are included in the hash used to produce addresses, did addresses using uncompressed keys &quot;change&quot; when compressed keys were introduced?</p>

<address><public-key>
Did uncompressed public keys use the `04` prefix before compressed public keys were used?
aryzing
# Did uncompressed public keys use the `04` prefix before compressed public keys were used?

(Asked by: username_0 on 2024-06-03)

Have uncompressed keys always used the `04` prefix, even before compressed keys (which use `02`, `03`) were used? Did bitcoin undergo an update to add these prefixes to the different key types? If so, since these prefixes are included in the hash used to produce addresses, did addresses using uncompressed keys "change" when compressed keys were introduced?

**Tags:** address, public-key


---

## 1 answers

### Answer by username_1 on 2024-06-03. Score: 2 | Accepted answer

> Have uncompressed keys always used the 04 prefix, even before compressed keys (which use 02, 03) were used?

Yes.

> Did bitcoin undergo an update to add these prefixes to the different key types?

There was no update to add prefixes.

Bitcoin wallet software did however undergo an update to make use of these compressed keys. There was no change to the consensus rules/implementation needed, because at the time OpenSSL was used for signature validation, and accepted both compressed and uncompressed public keys. In fact, there is a third type that was (and still is!) supported, *hybrid* keys, which use prefix `06` or `07` (depending on even/odd Y coordinate), followed by 32-byte X, *and* 32-byte Y coordinate. I do not understand the motivation for having such a type, but it is part of the implemented specification.

> If so, since these prefixes are included in the hash used to produce addresses, did addresses using uncompressed keys "change" when compressed keys were introduced?

If these prefixes were indeed not present at first then introducing them would have been a hard fork. Thankfully, no change was necessary.

Of course, wallets transitioning from uncompressed to compressed pubkeys did need to change addresses. But ony the receiver cares about the distinction, as the sender only sees the 160-bit public key hash. At spend time, the receiver needs to reveal the full public key, whose hash needs to match the public key hash sent to.

If you have an extremely old Bitcoin Core wallet.dat file that has never been updated, and load it into a very modern Bitcoin Core 27.0 software, it will still produce P2PKH addresses using the uncompressed public key, so that one can still go back to old versions. This will not keep working however, as legacy wallet support is scheduled to be removed from Bitcoin Core. Such old files will still be usable, but will need to be converted to a modern format first.

Also note that since the introduction of compressed public keys, there have been actual new address types (*with* corresponding consensus changes): P2SH, segwit, and taproot.


---

